可变性

副标题 / 摘要 可变值带来性能与直觉操作，不可变值带来安全与可预测性。本文从工程角度给出取舍指南。 目标读者 需要做语言/架构选型的开发者 经常处理共享状态与并发的工程师 想降低 bug 成本的团队负责人 背景 / 动机 “用可变还是不可变”常被当成风格问题，但本质是成本问题： 可变值降低了短期编码成本，却提高了长期维护成本；不可变值相反。 核心概念 可变值：对象可被修改，引用指向同一状态 不可变值：对象创建后不可变，修改通过创建新值 别名问题：多个引用指向同一对象导致隐式副作用 实践指南 / 步骤 核心业务规则优先用不可变 性能敏感且局部范围内用可变 共享数据优先不可变 用类型或约定明确边界 在接口处转换：可变在边界层，不可变在核心层 可运行示例 下面展示共享可变带来的副作用： nums = [1, 2, 3] ref = nums ref.append(4) print(nums) # [1, 2, 3, 4] 不可变方式： nums = (1, 2, 3) ref = nums ref = ref + (4,) print(nums) # (1, 2, 3) print(ref) # (1, 2, 3, 4) 解释与原理 可变值让“状态变化”隐式发生，易产生别名问题； 不可变值把变化变成显式的新值，便于推理与测试。 常见问题与注意事项 不可变一定更慢吗？ 不一定。结构共享与持久化数据结构可以降低成本。 可变值是不是更直观？ 对局部数据更直观，但对共享状态更危险。 如何混用？ 常见做法是“核心域不可变，边界层可变”。 最佳实践与建议 在并发场景优先不可变 在性能关键、局部封闭场景用可变 给团队建立明确的可变/不可变规范 小结 / 结论 可变值适合局部与性能场景，不可变值适合共享与核心逻辑。 真正的工程实践不是二选一，而是分层与约束。 ...