Clojure中使用let赋值是否违背函数式编程核心理念？

let 本质上和命令式编程里的赋值操作完全不是一回事，根本不是什么「向实用性妥协的折中方案」，纯函数式编程实践中完全不需要刻意回避它。

函数式编程倡导避免的「赋值」，特指对可变存储单元的覆写操作：这种操作会改变内存位置上存储的值，让同一个变量名在代码执行的不同阶段对应不同的内容，引入时序依赖的副作用，破坏代码的引用透明性，让代码逻辑难以推理。比如常见命令式语言里的写法：

let count = 0;
count = count + 1; // 直接修改了count绑定的存储位置的内容
console.log(count); // 不同执行阶段读取count会得到不同结果

而Clojure里的let做的事情是词法作用域内的不可变值绑定，和数学证明里「令x = 某个值，可推导xx结论」的逻辑完全一致：

• 绑定关系一旦确立，在对应的作用域里就永远指向同一个值，没有任何语法可以修改这个绑定指向的内容
• 就算你在同一个let里写了同名绑定，本质也只是内层/后置的绑定遮蔽了前面的名字，不是修改原有绑定的值
• 所有通过let绑定的名字都满足引用透明：你把代码里所有出现这个名字的位置直接替换成它绑定的实际值，程序运行结果不会有任何变化

举个最简单的验证例子：

(let [x 1
      x (inc x)]
  x)
;; 返回2，这里第二个x绑定的是(inc 1)的结果，根本没有修改第一个x绑定的1，只是第一个x的作用域到第二个绑定声明就结束了而已

很多人对let的误解，本质是把「给中间值命名」和「可变赋值」搞混了。函数式编程从来没有禁止给计算过程中的中间结果起名字——它反对的是可变状态和副作用，不是提升代码可读性的合理命名。

• 日常开发中完全不需要刻意规避let，用它把长嵌套表达式拆成有语义名字的中间步骤，反而能让代码逻辑更清晰，是符合函数式编程最佳实践的写法
• 真正需要注意的是不要滥用let模拟命令式的顺序执行逻辑，更不要把let绑定和atom/volatile!这类可变容器混在一起，写出带隐式副作用的代码——但这是可变状态的问题，和let本身没有关系。

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