Delphi开发：是否应为不修改的函数参数添加const关键字？

1. 为不会修改的参数使用const是否属于最佳实践？ #

是的，这绝对是Delphi开发的最佳实践之一：

• 从代码可读性来看，const能明确告知调用者和维护者：该参数的值在函数内部不会被修改，大幅降低理解代码的心智负担。
• 从代码契约角度，它相当于给函数加了一层约束，强制自己和后续维护者不能误修改参数值，避免不必要的bug。
• 官方文档和社区普遍推崇这种做法，在团队协作的代码库中，统一使用const能显著提升整体代码质量。

2. 将参数标记为const对性能或代码优化有影响吗？ #

有，但效果取决于参数类型：

• 值类型（如Integer、Double、自定义记录）：默认传参是值拷贝，const会让编译器直接传递参数引用（同时禁止修改），避免拷贝开销。对于体积较大的记录类型，这种优化的效果会非常明显。
• 引用类型（如字符串、类实例）：Delphi中引用类型本身传的是指针，但字符串默认有**写时复制（Copy-On-Write）**机制。const会跳过写时复制的检查逻辑，减少不必要的内存操作，提升性能。
• 接口类型：const会避免接口引用计数的增减，减少内存管理的额外开销。

不过对于单个Integer这类简单小值类型，性能提升微乎其微，此时const的价值更多体现在代码规范层面。

3. 使用const是否存在潜在陷阱或会导致意外行为的场景？ #

确实有几个需要注意的场景：

• 含可变成员的记录类型：如果参数是包含动态数组、接口等可变成员的记录，const仅禁止修改整个记录的引用，但允许修改记录内部的成员。比如：

  type
    TMyRecord = record
      Data: array of Integer;
    end;
  
  procedure Test(const R: TMyRecord);
  begin
    SetLength(R.Data, 1); // 此操作合法，会修改原记录的Data成员
    R.Data[0] := 100;
  end;
  

  这种情况会让调用者误以为参数完全不可修改，引发意外的副作用。
• 接口类型的const参数：const会跳过接口引用计数的增减，如果在函数内将接口变量赋值给非const变量，可能导致引用计数错误，进而引发内存泄漏或野指针问题。
• 与var/out参数混淆：const参数不能被赋值，否则会直接编译报错，需注意不要和用于传值回调用方的var/out参数搞混。

4. 有没有即使不修改参数也最好不使用const的情况？ #

存在几种场景不建议使用const：

• 兼容旧版本Delphi或特殊编译选项：部分非常老旧的Delphi版本对const的类型处理存在差异；若开启{$WRITEABLECONST ON}编译选项，const的约束会被绕过，失去原本的意义。
• 参数未来大概率会被修改：如果能确定后续需求会修改该参数，暂时不添加const可以避免后续的代码变更（不过更推荐先遵循契约式编程加const，真要修改时再移除）。
• 临时调试需求：如果需要在调试时临时修改参数值测试逻辑，const会限制这种操作，但这属于临时场景，不应作为长期不使用const的理由。

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