学习Swift的人越来越多但真正能把let用明白的说实话不多。很多同行写了几年Swift提到常量仍然只会说let就是不可变的var可一旦深问下去——常量什么时候能延迟初始化、常量和并发安全有什么关系、为什么别人代码里的let能参与编译期优化而你的不行——十有八九答不上来。这篇文章就围绕Swift常量这个核心主题把我这些年实际项目里积累的经验、踩过的坑、以及从编译器和并发底层视角看到的东西一次性梳理出来。不论你是刚入门Swift的新手还是已经写了几年iOS的老手只要想彻底吃透常量这两个字这篇内容都值得认真看看。1. Swift常量的核心概念let不只是不能改的变量1.1 let的本质一次性绑定而非不可变数据先说结论Swift里的let声明的是一个绑定不可变的常量。意思是let创建的标识符一旦绑定到某个值就不能再绑定到另一个值。可以理解为坐位已经定死中途不能换人。这里必须要澄清一个很多人误解的地方let保证的是引用不能变不是指向的内容不能变。这个区分在Swift里极其重要直接决定你会不会写出隐蔽的bug。举个例子class Counter { var count 0 } let counter Counter() counter.count 10 // 编译通过且运行正常看到这里很多人会疑惑counter不是常量吗为什么还能改因为let锁死的是counter这个变量对Counter()实例的引用关系而不是该实例的内部状态。你在内存里的对象本身依然是类实例依然可以被修改。真正的彻底不可变需要配合值类型struct或者final class加不可变属性设计才能实现。为了更好理解可以把let想象成一根固定的绳子绳子系在哪个桩上已经定了但绳子拴着的那头狗还可以自己走动。这就是引用类型下let的真实状态。1.2 let与var的对立语言设计者希望你默认选谁Swift的语法设计里let和var的地位并不是对等的。官方建议很明确优先使用let。原因很直接——let制造的是不可变绑定编译器可以做更多假设代码的安全性更好可读性也更高。我在做代码评审的时候看到一些老手写Swift仍然频繁使用var理由通常是反正后面可能会改。这个习惯如果是从其他语言带过来的其实在Swift里要吃大亏。Swift编译器对let的优化力度非常大一个能用let却用了var的代码等于主动把编译器的优化空间砍掉一块。更麻烦的是var变量被捕获到闭包里会持有独立的存储在某些场景下还会引入额外的内存开销。从代码的可读性角度讲let也是一个很好的信号。阅读代码的人看到let就知道这个值在整个生命周期里不会变思维负担一下就轻了。看到var则要额外注意它在什么时候、在什么条件下被修改。默认用let不仅是对编译器好更是对未来读代码的同事好。1.3 值类型常量的深层次保证当let修饰的是值类型struct、enum、元组等时编译器层面的保证就强很多了。值类型遵循写时复制策略或者直接内联存储let意味着这个值本身以及它的属性都不能被修改。struct Point { var x: Double var y: Double } let origin Point(x: 0, y: 0) // origin.x 10 // 编译错误Cannot assign to property: origin is a let constant这种情况下的let接近很多人理解的对象本身不可变。尤其是配合Swift的struct在设计上的值语义let声明的结构体实例会获得真正的不可变性——不仅是当前绑定不可变它所有存储属性也被冻结。这里有一个实用技巧如果你在设计API时希望暴露一份只读数据优先使用letstruct而不是返回一个class实例然后期望调用方自觉不去改。前者是编译期强制约束后者只是道德约束。我在团队里推这个原则推了很久后来发现凡是遵守这个原则的模块跨类协作的bug率明显更低。2. 声明常量的最佳实践从入门到进阶的选型指南2.1 为什么能let尽量let是Swift第一铁律Swift社区的共识里let优先几乎是最不可能被反驳的一条建议。原因不复杂编译器优化空间更大。let绑定可以在编译期被标记为不可变可以安全地进行内联、常量折叠、死代码消除。减少状态空间。不可变绑定意味着更少的运行状态变化代码推理门槛更低。避免意外修改。var很容易在复杂逻辑中被无意改写let从根上杜绝这种可能性。在实际项目里这条规则的执行力度取决于团队规范和代码评审的认真程度。我自己做评审的时候看到新的var第一句就问能不能用let如果不能请写注释说明为什么必须可变。这个动作坚持了半年整个项目的let/var使用比例从大概7比3变成了9比1崩溃率也有肉眼可见的下降——虽然崩溃下降不完全归功于此但减少状态修改确实降低了一批逻辑互踩的crash。2.2 类型推断让常量的声明更干净Swift的类型推断能力很强let搭配类型推断可以写出非常干净的代码let count 100 // Int let name Swift // String let ratio 0.618 // Double let isReady true // Bool但要注意类型推断在某些边界场景下会给出和你预期不同的类型。比如小数如果直接写let x 0.5推断出来的是Double这在Swift里是很关键的一个类型选择。再比如let count: Int 100 let count2 100这两条声明的效果几乎一样因为整数默认推断为Int。不过如果你需要明确的宽度比如Int64、UInt8就必须显式标注类型否则默认推断会落在Int上。小数同理Float和Double的精度差异很大经验不足时很容易写出因类型推断导致的计算误差。建议是API边界处显式写类型内部实现可以依赖推断。边界处显式标注可以让调用方明确知道预期类型内部实现保持简洁即可。2.3 static let单例常量与全局常量的正确姿势Swift里推荐用static let创建类型级别的常量这种写法天然是线程安全且惰性初始化的lazy只初始化一次。很多老iOS开发者应该还记得Objective-C时代写单例那一大坨dispatch_once代码Swift的static let把这些全处理了。enum AppConfig { static let apiBaseURL https://api.example.com static let maxRetryCount 3 static let requestTimeout: TimeInterval 30 }用enum作为命名空间是Swift社区的惯用做法好处是不会有人不小心创建AppConfig()实例因为enum没有可用的初始化器。而且所有常量集中在一处管理和查找都很方便。更有意思的是static let的惰性初始化机制还天然解决了并发安全的问题。无论多少个线程同时首次访问这个属性系统保证只有一个线程执行初始化其他线程等待结果。这部分机制底层其实就是Swift runtime里的dispatch_once逻辑但语法层面被隐藏得非常干净。2.4 元组常量与模式匹配Swift的元组和模式匹配配合let非常灵活let coordinate (x: 3, y: 5) let (width, height) (1920, 1080)解构声明是let的常见用法。在遍历字典、处理枚举关联值时特别顺手for (key, value) in someDictionary { // key和value都是常量 }元组解构配合if case、guard case之类的模式匹配能让代码变得非常声明式大幅度减少临时状态。这种风格对Swift新手可能有点陌生但只要习惯了写出来的代码会明显更紧凑、可读性更好。3. 常量的幕后世界编译器优化与静态值语义3.1 编译期常量与运行时常量的差异很多人分不清编译期常量和运行时常量但这两个概念对性能的影响差别巨大。编译期常量的值在编译时就已经确定比如let maxFileSize 1024 * 1024当这个常量参与了运算时编译器可以直接把1024 * 1024计算成1048576这就是常量折叠。对整个表达式中的其他常量编译器也可能直接生成最终结果省掉一次乘法运算。而运行时常量只在运行时确定一次编译器没法提前知道值优化空间就小很多。这里提一个和Java对比的有趣现象。Java语言规范里对static final常量有明确的编译期常量compile-time constant概念要求final基本类型变量用字面量或编译期常量表达式初始化然后编译器会遇到常量表达式必须含有常量值这类错误提示。Swift里没有完全相同的规范但let字面量的模式同样触发了编译器的常量优化路径。3.2 表达式必须含有常量值的本质那段在Java和部分C场景常见的编译错误表达式必须含有常量值核心意思是你想把一个变量当常量用但它不是编译期可确定的。Swift不直接报这个文案但你在某些场景下会碰到相似的约束。典型场景是数组的尺寸、enum的底层值或者某些需要编译期固定大小的位置。Swift里虽然没有C那种数组长度为编译期常量的需求但如果你用let声明常量时依赖的是运行时才能确定的值编译器仍然会明确告诉你let不能在初始化时引用自身或者在类型上下文中不符合要求。从这个错误里可以提炼出一条通用经验编译器希望常量的常量性是它自己可以验证的而非你口头承诺的。如果某个值确实需要从用户输入、网络请求、配置文件读取那它本质上就是运行时值该用var就不用硬扛let。为了用let而强制重构出反直觉的代码通常得不偿失。3.3 字符串常量转换从字面量到常量字符串字符串在常量这个话题上有个独特地位。Hello这样的字符串字面量在Swift里会被推断为String类型。每次编译时字符串字面量会生成对应的运行时对象如果你反复在多个位置写同一个字面量编译器和运行时有一定的共享机制但效果取决于你如何使用。一种常见的转换为常量字符串最佳实践是把散落在代码各处的魔法字符串收敛为static let常量。比如:enum NotificationName { static let userDidLogin UserDidLogin static let userDidLogout UserDidLogout } enum CellIdentifier { static let articleCell ArticleCell static let profileCell ProfileCell }这样做的价值不仅仅是少打几个字而是让字符串在整个代码库里有唯一来源。出问题时你只需要改一处不用担心某些地方漏改。我记得多个项目里都出现过因为字符串拼错一个字母导致界面没反应、又很难排查的case收敛成常量之后这类问题基本绝迹。如果要追求更深度的性能优化可以考虑将频繁构造的字符串用StaticString或UnsafePointer存字面量但那属于极端优化场景普通App完全不必要。更重要的是代码可维护性而不是省下那几纳秒。3.4 静态常量与资源配置的选择工程实践里还有一类常数其实是配置文件。比如后台地址、开关阈值、功能开关等。这里有个非官方的经验准则代码里变动频率 发版周期的常量放代码里变动频率 发版周期的配置放远端或本地配置文件里。static let虽然方便但它跨发版周期更新非常麻烦——你必须发新版本才能改。而远程配置、Firebase Remote Config之类的方案则能在不发版的情况下调整。这两种方案的边界要分清楚。我见过不少团队把本应放配置的东西写死成常量结果每次运营调参都要发包苦不堪言。4. 常量的并发安全价值面试里说不清的知识点4.1 为什么let天然具备并发安全优势Swift并发安全这个热门话题和常量有着非常直接的关系。并发编程里的大多数bug——数据竞争、内存踩踏、逻辑错乱——根源都在于可变状态被多个线程同时读写。let声明的不可变绑定从语言层面消灭了可变状态存在的可能性因此自然不会有数据竞争。这句话说得轻巧但内里非常硬核。Swift的并发安全体系由三块构成值类型、不可变性let、以及Actor模型。值类型天然避开了多个线程共享同一块内存的可变引用let确保不会被重新赋值Actor则将可变状态隔离到独立的串行执行域中。三者配合构成了Swift相对其他语言更安全的并发环境。从Swift 5.5引入async/await和Actor之后常量和并发安全的关系又更近了。现在的并发编程建议里尤其强调以不可变数据传递为主。把一份不可变数据传递给并发任务就完全不需要担心任务内部把它改坏因为语言层面它就不可能被改。4.2 常量在并发场景中的实际演示看一个典型例子从多个并发任务中读取共享配置。struct AppSettings { static let shared AppSettings( maxCacheSize: 100, enableLogging: true ) let maxCacheSize: Int let enableLogging: Bool } Task.detached { let settings AppSettings.shared // 使用settings无需加锁 }这里的关键点在于AppSettings的全部属性都是let这意味着即使多线程访问同一个shared实例也不会有数据竞争。相反如果这些属性被写成var你就必须在每个读取点加锁或者使用原子操作代码复杂度会上一个台阶。另一个常见模式是let配合函数式写法的并发分发let numbers [1, 2, 3, 4, 5] let results await withTaskGroup(of: Int.self) { group - [Int] in for number in numbers { group.addTask { compute(number) // number是let常量闭包内安全访问 } } var collected: [Int] [] for await result in group { collected.append(result) } return collected }numbers是let声明的数组被多个并发子任务只读访问不需要任何加锁。反过来如果是var numbers即使没人修改它编译器也无法充分证明安全性某些判定严格模式下会引发警告甚至被审查者打回。这就是常量带来的并发安全红利。4.3 闭包捕获let与引用类型的例外这里有个很常见的陷阱闭包捕获let引用类型时不可变性只对引用对象本身有效而指向的内容依旧可变。举个经典嵌套场景class MutableState { var value 0 } let state MutableState() DispatchQueue.concurrentPerform(iterations: 10) { _ in state.value 1 // 数据竞争即便state是let }这段代码照样会产生数据竞争因为state虽然是let但它是引用类型内部的value是var。三个线程同时1结果不确定。破解之道很简单要么把MutableState改成struct并使用let要么放到actor里隔离要么把value也设计成常量然后通过复制传值。我见过非常多的并发bug追根溯源都是这个模式开发者以为let保平安了结果let住的只是一个引用指针。所以说Swift安全不安全直接甩锅给语言并不公平正确定位是语言提供了工具但用对工具还得靠人。5. 实际项目中的陷阱与排查技巧实录5.1 声明了常量却试图修改它这是Swift编译器报错里最经典、频率最高的一类let total 0 total 1 // 编译错误Left side of mutating operator isnt mutable: total is a let constant这类错误通常发生在重构过程中或者把其他语言的代码直接翻译成Swift时。Java里写final不能重新赋值但可以通过循环不断构造新变量更新引用Swift里let一旦绑定就不行。解决方式是改成var或者换一种更函数式的写法不修改旧变量而是创建新值。我个人的经验如果你发现代码里到处都是为了小改动而把let改成var那说明这段代码的设计可能没有考虑好状态的流转真正的修正不是机械地把let改var而是重新梳理这批数据的流向尽量让每个值在各自的上下文里一次性确定。5.2 延迟初始化与let的组合拳很多人不知道let可以在多条执行路径上一次性赋值只要编译器能确定在首次访问前赋值一次即可。let name: String if isLoggedIn { name user.name } else { name Guest } print(name)这个特性在Swift里叫deferred initialization延迟初始化。它非常有用能在保持let不可变性的前提下根据运行条件决定初始值。要注意的是编译器要求每条可能的执行路径都必须给let赋值且只能赋值一次。如果你漏了某条路径编译器会报variable name used before being initialized此时检查所有分支是否都完成了赋值即可。对比一下Java里final的blank final变量其实思路很相似。但Swift的编译器检查更加友好错误信息也更能引导修复。5.3 静态库和框架间的常量可见性在大型项目里常量的访问级别internal、public、open常被忽视。一个模块里用public static let暴露常量时要考虑它是否会被外部模块依赖以及它会不会被objc运行时桥接影响。尤其在使用Objective-C混编的老项目里Swift常量和OC宏定义之间的转换有几个经典坑OC的#define是纯文本替换编译期直接替换没有类型、没有作用域。Swift的let是真正的类型化常量有作用域有访问控制。如果你在OC里通过#import Module-Swift.h访问Swift常量需要使用objc暴露的类属性或者直接使用C风格全局常量。在实际工程中跨语言常量不一致是bug高发区。最佳实践是选定一种语言作为常量定义主源另一种语言通过桥接引用避免同一常量在两处分别定义。这个建议听起来简单但在真实项目里落实需要很多评审会议来推进。5.4 let常量折叠调试时的奇怪现象有时候你在调试器里看到let变量行为似乎变了其实背后是编译器做了优化。在Release模式下编译器会把确定的常量折叠成字面量调试器显示的某些中间状态可能不符合你基于源码的直觉。这种情况在Debug模式下基本不会出现所以排查诡异常量问题时的第一步永远是确认当前构建配置。一条实用建议如果你需要在Release模式下断点调试常量的真实内存地址请在变量声明处加上inline(never)或者关闭该函数的优化否则编译器可能把变量优化得不存在了。这不是bug这是编译器的正常工作方式。5.5 常量命名与代码可读性的平衡let常量的命名在Swift社区里遵循驼峰命名maxCacheSize但类型级别的static let同样使用驼峰这和很多其他语言用全大写不同。很多从C/C/Java转来的开发者会本能地写出MAX_CACHE_SIZE这种全大写命名这在Swift里反而不符合语言惯例。全大写在Swift里一般保留给某些特殊场景例如Enumcase 的比较或者Apple框架里少数screamCase常量。用驼峰的好处是阅读自然和类型、方法命名风格统一。但如果整个团队来自不同语言背景那最好在团队规范里明确这一点否则混用命名风格会让代码库观感很乱。强制统一命名风格看上去像强迫症但它其实是降低认知开销、提高评审效率的一种低成本高回报做法。合理的常量子设计和命名约定是对代码库长期健康的有力保护。最后再分享一个工作中的小习惯做完这个主题总结后我想把你经常忽视的一个细节分享出来在写let的时候养成先问能不能let再问要不要var的思考顺序。听起来非常简单但真正坚持一段时间你就会发现整个编程思维都在往数据流优先、状态最小化的方向靠拢。在并发和Async/Await大行其道的今天这种思维的价值比一年前更大了。如果只记住一句话我希望你记住的是Swift里的let从来不只是不能改的变量这么简单它是连接代码安全、并发安全和编译优化三件事的钥匙。把let用明白是你写出高质量Swift代码的第一步也是最值得的一步。