原文：Swift Basics: The Real Difference Between let and var Explained with Examples

很多初学 Swift 的同学会把 let 和 var 的区别简单记忆成“常量 vs 变量”。

但在实际工程中，这条规则只是起点。选择 let 还是 var 会直接影响代码的安全性、可读性，甚至运行时性能。

基础语义：可变与不可变

• var：可变变量。值在生命周期内可以被重新赋值或修改。
• let：不可变绑定。一旦赋值，就不能再指向别的值。

// var 可以改
var score = 10
score += 5          // ✅ 11

// let 不能改
let pi = 3.14
pi = 3.1415         // ❌ Cannot assign to value: 'pi' is a 'let' constant

何时用 let，何时用 var？

官方社区的最佳实践：“先写 let，必要时再改成 var。”

这条规则背后的逻辑是：

1. 不可变数据天然线程安全，减少副作用；
2. 编译器可以做更多优化（如栈上分配、内联）；
3. 阅读代码的人无需担心值被中途篡改。

示例：

let identityNumber = "12345678900"   // 一辈子不会变
var currentCity      = "Erzurum"     // 用户可能搬家

let 真的“绝对不变”吗？

答案是：取决于类型是值类型（Value Type）还是引用类型（Reference Type）。

引用类型（class）

class Person {
    var name: String
    init(name: String) { self.name = name }
}

let person = Person(name: "Turabi")
person.name = "Muhammed"   // ✅ 合法！

• person 这个“变量名”不能指向别的对象；
• 但对象内部的属性仍可以变动。

值类型（struct / enum）

struct Book {
    let title: String
}

let book = Book(title: "1984")
book.title = "The Art of War"   // ❌ Cannot assign to property: 'book' is a 'let' constant

• 值类型实例被 let 修饰后，整个实例及其所有属性都不可变；
• 如果想改属性，需要把实例声明为 var，或者把属性声明为 var。

小结与实战 Checklist

1. 默认用 let，除非编译器报错提示你需要可变性。
2. API 模型全部用 let，除非后端明确会推送增量更新。
3. UI 状态（如 @State 属性）用 var。
4. 多线程或并发场景，优先把数据设计成不可变，减少锁竞争。
5. 如果想让对象内部也不可变，考虑：
   • 把 class 改成 struct；
   • 或者把内部属性全部设为 let。

附：完整示例

// 1. 值类型：struct
struct Point {
    let x: Int
    let y: Int
}

let p = Point(x: 0, y: 0)
// p.x = 10   // ❌

// 2. 引用类型：class
class Counter {
    var value: Int = 0
}

let counter = Counter()
counter.value += 1   // ✅
// counter = Counter()   // ❌

选择 let 或 var 不仅是语法风格问题，更是设计决策。

当你写下 let 的那一刻，就向未来的维护者传递了“这里不会被意外修改”的承诺。

前沿技术周刊 是一份专注于技术生态的周刊，每周更新。本周刊深入挖掘高质量技术内容，为开发者提供持续的知识更新与技术洞察。

订阅渠道：【零一开源】、 【掘金】、 【RSS】

大厂在做什么

• 美团智能头盔研发实践系列02：软件功能篇

• 哔哩哔哩Android视频编辑页的架构升级

• 半年研发、1 周上线，1 秒 200 行代码爆发

• 2025 Google 开发者大会主旨演讲精华汇总

• 让AI读懂代码需求：大模型微调训练实践及端侧运行部署

• Taro on HarmonyOS 技术架构深度解析

• B站是如何实现原声视频翻译的

• 播放器音频后处理实践

码圈新闻

• 2025 年 AI 的落地程度远比我们想象的广

• 2025 Google 开发者大会 客户端要点速览

• OpenAI 首个开源模型已上线

• 一文看尽世界机器人大会

• GPT-5，重磅来袭！

深度技术

• 深入 ART Dex 加载流程，玩转 Android 通用脱壳点

• 万字长文解码如何玩转Prompt（附实践应用）

• 解密 Cursor：一位深度用户的原理探析与实验验证

• 解锁多模态大模型 InternVL2-2B：训练、微调与部署实战全攻略

• 小白都能看懂的RAG分块实战

新技术介绍

• Jetpack Compose 1.8 新增了 12 个新特性

• Flutter 3.35 发布，快来看看有什么更新吧

• TheRouter 1.3.0 版本发布，业界领先移动端全平台路由框架

• AI在实际生成环境中的提效实践

博客推荐

• Android: 适配 16KB 页面大小：提升应用性能并为用户提供更流畅的应用体验

• Android: 深入浅出Android的Context机制

• HarmonyOS: 鸿蒙ArkWeb加载优化方案详解

GitHub 一周推荐

• 其他: Qwen-Image

关于我们

【零一开源】 是一个 文章 和 开源项目 的分享站，有写博客或开源项目的也欢迎来提供投递。 每周会搜集、整理当前的新技术、新文章，欢迎大家订阅。

youtube链接

整洁架构之道

架构是个让大家又爱又恨的话题，谁都可以说上两句，但又不一定所有人能把它说清楚。不过归根结底，你见得多了，想得多了，实践得多了，思考得多了之后，都可以最终达到领悟的状态。本文接下来就给大家提供一些基于Clean Architecture这本书的洞见。

首先，对一个软件项目的整体架构进行治理的首要目的是代码可读性，可复用性，可测性，可维护性，所以如果你的项目本身规模不大，比如一个只有一个功能的demo项目，使用简单的MVC架构，分目录归拢代码就能清晰在划分出对应职责，那这种时候你不需要花额外精力来治理架构

那么对于一个大型的且需要持续迭代的项目来说，架构治理会是一个必然的要求，因为随着代码量的增加，项目复杂度和改动成本的不断增加，以及随之而来的功能稳定性问题会是项目能否持续向前演进的关键。

今天我们主要说一下Clean Architecture这个技术流派是以什么出发点，用什么方法来解决架构问题。

软件架构面临哪些问题

• 代码复杂度
• 人员变动
• 重构
• 替换模块

所有这些都指向一个要求，能够让开发者不借助外力的情况下知道改哪些代码，怎么改

怎么解决呢

这本书系统地介绍了架构的相关知识，基于整洁架构的洋葱模型对工程代码进行分层从而实现关注点分离。降低项目维护成本，实现项目的“快稳狠”。

其它架构是怎么解决的

六边形架构（Hexagonal Architecture）
又称为端口与适配器（Ports and Adapters），由 Alistair Cockburn 提出，并在 Steve Freeman 与 Nat Pryce 的经典著作 Growing Object-Oriented Software 中得以推广。

洋葱架构（Onion Architecture）
由 Jeffrey Palermo 提出。

尖叫架构（Screaming Architecture）
出自作者Uncle Bos 2011年的一篇博客。

DCI 架构（Data-Context-Interaction）
由 James Coplien 与 Trygve Reenskaug 提出。

BCE（Boundary-Control-Entity）
由 Ivar Jacobson 在其著作 Object-Oriented Software Engineering: A Use-Case Driven Approach 中提出。

虽然这些架构在细节上有所不同，但它们非常相似。它们的共同目标是 关注点分离（Separation of Concerns） 。也就是都通过将软件划分为不同层次来实现这种分离。每种架构至少都有一个用于 业务规则（business rules） 的层，以及另一个用于 接口（interfaces） 的层。

这些架构产生的系统具备以下特性：

1. 与框架无关
   架构不依赖某些功能繁多的软件库的存在。这样你可以把框架当作工具来用，而不是被迫把系统塞进它们的局限里。
2. 可测试
   业务规则可以在没有 UI、数据库、Web 服务器或其他外部元素的情况下进行测试。
3. 与 UI 无关
   UI 可以轻松更换，而无需修改系统的其他部分。例如，可以将 Web UI 替换为命令行 UI，而无需改动业务规则。
4. 与数据库无关
   可以将 Oracle 或 SQL Server 替换为 Mongo、BigTable、CouchDB 等，而业务规则不会受到影响。
5. 与任何外部机构无关
   业务规则对外部世界一无所知。

下面将讲到的整洁架构的图示，正是试图将这些架构整合成一个可执行的统一理念。

整洁架构怎么解决呢

用书里面的话来说判断一个软件架构的优劣，可以用它满足用户需求所需要的成本来衡量。如果该成本很低，并且在系统的整个生命周期内一直都能维持这样的低成本，那么这个系统的设计就是优良的。如果该系统的每次发布都会提升下一次变更的成本，那么这个设计就是不好的

最重要的原则是依赖原则，依赖只能向内。也就是内层不应知道任何外层的细节，包括但不限于函数、类、变量、数据格式或任何其它实体。

参考文档

整洁架构解读

参考链接