Swift在class作用域之外定义全局常/变量引发的血案
先上结论——
不要随便在class作用域之外声明 需要获取外部信息来创建的伪·常量 ！！！
我们在做开发的过程中，经常会有一些只在某个文件需要用到的常量，这些变量一般我们会使用如下方式进行声明：
fileprivate let someConst = "xxxxxxx"
fileprivate let anotherConst = [a, b, c, d]
class SomeClass {
// ......
}
这种情况下，我们可以只在该文件中访问这些常量，并且不用担心被修改，且是应用一启动就一定存在的，访问起来也非常高效和安全。
但是，某次在开发中遭遇了一个表面看来不可能的Bug，事情是这样的
1) 这个AppMainController中组件的布局依托于model里的数据
2) model的来源有两个——初始化的时候查找对应用户名的缓存model并加载，以及网络请求返回数据后用网络数据刷新界面并重新缓存对应用户名的model
3）不同的用户名对应着不同路径下的缓存，也就是下面的userAppDocPath
初始代码如下所示：
fileprivate let userAppDocPath = NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true).first! + "/\(STDUserDefaults.sharedInstance.userName ?? "defautUser")_cachedAppModel"
public class XXXAppMainController: UIViewController {
//.......
}
这样处理之后，好像一切都很完美，每次都能拿到缓存，即使某次没有网络也能正常加载controller😏
直到某天，我退出自己的帐号，无意中登录了同事的帐号……😕意外发生了——这个界面居然会先闪一下我的帐号对应的业务控件😵，然后再加载同事的帐号对应控件……而且，此前我并没有登录过同事的帐号。
这，这是要搞事情啊，一定有问题。再试一次，这次我已经两个账号都登录过了，本地应该有两套缓存，然而事实是，只要我登录了帐号A，再退出登录去登录账号B，每次都会先闪烁帐号A对应的数据……
那么如果这样登录呢？
flow
st=>start: 登录帐号A
e=>end
op1=>operation: 登录帐号B
op2=>operation: 登陆账号A
op3=>operation: 登录帐号B
st(right)->op1(right)->op2(right)->op3(right)->e(right)
st=>start: 登录帐号B
e=>end
op1=>operation: 登录帐号A
op2=>operation: 登陆账号B
op3=>operation: 登录帐号A
st(right)->op1(right)->op2(right)->op3(right)->e(right)
哎哟我勒个去……简书的MarkDown编辑器暂时不支持流程图……那就用文字再来一遍，万一哪天它支持了，上面的就能看了……
登录帐号A→登录帐号B→登录帐号A→End
登录帐号B→登录帐号A→登录帐号B→End
一个本该理所当然但是当时感觉很奇葩的事情发生了——无论反复登录多少次，都会在加载视图的时候，闪烁 第一次登录的帐号 对应的数据。
到此，我们已经可以大胆猜测出问题了
每次获取缓存路径，拿到的都是启动App后第一次登录的账号对应的缓存路径。
既然如此，我们就回头看看代码中对userAppDocPath定义的声明。
fileprivate let userAppDocPath = NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true).first! + "/\(STDUserDefaults.sharedInstance.userName ?? "defautUser")_cachedAppModel"
public class XXXAppMainController: UIViewController {
//.......
}
可以看到，我确实是从userDefaults中获取了当前用户的用户名作为component的，那么只有一种可能了，自从App启动之后，这个path就再也没有被重新生成过，无论这个controller是否被销毁……🤔
OK，这下我就更深刻地明白了——
在class作用域之外声明的常量，是作为全局常量存在内存中的 全局常量区 中的，跟App同生命周期。
因此，我定义的这个所谓的“常量”，只是对于AppMainController这个类来说是个常量，而作为全局常量来说，它绝对是个伪·常量！
我们要做的就是，把它，放回属于它的地方！
代码变成这样——
public class XXXAppMainController: UIViewController {
fileprivate let userAppDocPath = NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true).first! + "/\(STDUserDefaults.sharedInstance.userName ?? "defautUser")_cachedAppModel"
//.......
}
测试，A切B，B切A，A再切B……无论怎么测试，这个逻辑都正常了……
这个故事告诉我们……需要动态获取信息来创建的常量，只要存在App运行中改动的可能，就一定不要定义在class作用域之外……当然这个tip可能并不艰涩，但是，如果一不留神作出了这样的声明，可是会在找Bug的时候很头疼的……
P.S.：我一个朋友果然在某次开发中也遇到了同样的问题。在class之外定义了一个Array，然后他搞了半天不明白为什么自己的View都释放了，Array里的元素还被持有着……直到我看了一眼他的代码头部……你懂得，故事完美结束，没有发生事故😏
