※ 引述《tkdmaf (皮皮快跑)》之铭言：
: https://gist.github.com/tkdmaf/19790d5bb9f0f3c5070b0d3f364d7071
: 各位如果有空，可以测试这里面的code吗？
: 有个很奇怪的不确定是不是苹果爸爸的Bug.....
: 这当中，只要sub层的Codable中的property假设型态都是String时。
: 只要总合加起来是“14”个，在某些版本或装置上就会闪退……
: (或是我测过String有13个，Int有2个，这种情形也会闪退)
: 有测试的，麻烦请告知：
: CPU：Intel或是M1
: XCode版本、iOS装置及版本(请至少测三种，而且一定要测 15.4)
: 如果最终认定是apple的Issue，可能有必要回报给apple了。
: (我在执行公司的专案中……意外的发现了这个状况。)
: 在几个line群组，有测试的回应有的人会闪退，有的人不会……
: 有点神奇……
本来想说修改文章好还是回自己的文章好。
想了想还是回文吧。
首先，这个问题比较神奇的是同样的Code有人会闪退有人不会闪退。
就算同样是iOS 15.4也是有人闪有人不闪。(也不确定跟手机型号有没关系)
然后就在昨天深夜某位朋友传讯息给我并改了我写的东西加了一点让我自己看。
因为昨晚累的半死我没什么思考能力，早上才又问他。
大致得到的结论是：
因为struct是call by value。
在跨thread回传资料时可能因为某个条件符合导致回传(组语显示的是mov)
可能从这个内存搬到另一个位置时出些了不可预期的问题。
但如果改用class来宣告Codable的资料结构的话。
因为class是call by reference，不会有内存搬迁(mov的行为)。
而是跨thread后仍然是参考原本的内存位置，所以就没有带出那个不可预期的问题。
当然这都只是猜测。虽然测试上来说，确实改成class来宣告Codable时就不会产生
这样的问题。而且通常都是用于网络资料请求，所以也不太可能发生内存参考泄漏的
状况。
总之……就是一个我专案突然闪退让我花了很长的时间一个一个去测才测出这奇怪
闪退的规则(我暂时称之为14个String的结构bug，当然不只有14个String的状况会
发生，不同的型态，有可能会造成这个数字的增减……估计可能跟该属性占用的byte有
关连………)