为什么在函数式编程中使用赋值是不良实践？

首先澄清一个常见误解：你提到的「函数内部执行赋值就不会影响纯函数特性」，只适用于一次性的不可变绑定场景——也就是变量定义后永远不会被二次修改、也不会逃逸出函数作用域的情况，这种行为本质上是给固定的表达式起别名，不属于函数式编程反对的「可变赋值」范畴。我们通常说要避免的赋值，特指对已经完成绑定的变量重新修改值的行为。

不符合最佳实践的核心原因包括：

• 破坏引用透明性
  可变赋值会直接打破「相同输入永远得到相同输出」的纯函数特性。哪怕你暂时把可变状态限制在函数内部，后续重构时很容易不小心让可变状态逃逸到外部作用域，导致相同入参返回不同结果。同时可变赋值也让代码失去了表达式可替换性：你无法直接用变量的定义值替换代码中出现的变量，调试时必须回溯所有修改过该变量的位置才能确定当前值，排查问题的成本会大幅提升。
• 提升代码认知负担
  纯函数式代码中所有变量的值在定义时就完全确定，读代码时不需要额外追踪变量的变化历史。如果代码中存在可变赋值，你需要时刻记忆当前位置的变量有没有被之前的逻辑修改过，在嵌套逻辑、循环逻辑中这种负担会被指数级放大，非常容易出现意料之外的逻辑错误。
• 阻碍编译器优化
  对于不可变绑定，编译器可以安全地做常量折叠、公共子表达式消除、指令重排、甚至自动并行化等大量优化，大幅提升代码运行效率。如果存在可变赋值，编译器只能保守假设变量随时可能被修改，绝大多数优化逻辑都无法生效，反而会降低运行性能。
• 降低并发场景安全性
  函数式编程的核心优势之一就是无共享可变状态，天生线程安全，不需要额外加锁就能安全地做并发/并行开发。如果代码中存在可变赋值，哪怕当前被限制在函数内部，后续如果要改造为异步执行、或者提取公共逻辑让变量被多线程共享，就会极容易出现竞态条件，这类问题的排查成本非常高。
• 破坏代码的代数推导能力
  纯函数式代码符合代数运算规则，你可以像做数学题一样对代码做等价变形、重构，不用担心逻辑出错。可变赋值的存在会打破这种等价性，比如let x = 1; x = 2; return x和直接return 2看似等价，但如果中间有其他依赖x的逻辑，重构时就会出现不可预知的问题。

补充说明：多数函数式编程语言都支持不可变绑定，比如Haskell的let、Scala的val、JavaScript的const（仅赋值一次），这类操作并不会违反函数式编程的设计原则，反而可以提升代码的可读性。

内容的提问来源于stack exchange，提问作者David