PowerShell中何时应选择定义常量而非普通变量？

两种定义方式的核心差异是写入后是否允许修改：

• 普通变量直接赋值（$test = 100）：定义后可以随时修改值、删除变量，没有任何强制约束。
• 常量定义（Set-Variable test -Option Constant -Value 100）：一旦在当前作用域定义完成，任何修改值、删除变量的操作都会直接抛出错误，哪怕加-Force参数也无法绕过，值在当前作用域生命周期内完全固定。

优先选常量的核心判断依据 #

只要满足这个值在脚本/当前作用域的整个运行周期内，逻辑上绝对不允许被修改这个条件，就应该优先用常量，而不是普通变量。本质是用PowerShell的原生语法约束，避免意外篡改带来的无意义bug。

常量的典型适用场景 #

• 硬编码的固定配置项：比如脚本固定使用的服务端口、内置资源的固定安装路径、日志输出的固定根目录、对接第三方服务的固定API版本号这类写完就不会变的配置值。举个实际用例：

  Set-Variable DEFAULT_LOG_PATH -Option Constant -Scope Script -Value "D:\service\app\logs\"
  

  后续如果有代码手滑写了$DEFAULT_LOG_PATH = "C:\temp\"，PowerShell会直接抛出变量只读的错误，第一时间暴露问题，不会让错误值流到后续逻辑里。
• 业务/计算规则的固定基准值：比如计算逻辑里用到的固定换算系数、业务规则定死的密码最小长度、活动满减的固定门槛值这类全脚本逻辑必须统一引用的基准值，用常量可以避免出现不同代码段里值不一致，导致计算结果前后矛盾的问题。
• 防篡改的敏感固定值：比如脚本内置的签名校验哈希、加密用的固定公钥这类涉及安全校验的值，用常量定义可以避免运行时被恶意注入的代码篡改，绕过安全校验逻辑。

不适合用常量的场景 #

如果值会随着脚本运行动态变化——比如用户传入的启动参数、运行中计算生成的中间结果、需要根据环境动态调整的配置项，直接用普通变量即可，不要强行定义成常量。

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