配置可选项被清理后，服务端却把字符串 "undefined" 当成真实值使用，这类问题很容易藏在默认值逻辑里。原因是 process.env 看起来像普通对象，但它承载的是环境变量映射；赋值和删除遵循的操作不同。把 undefined 赋给属性，并不等于把那项移走。
赋值不会触发对象属性删除
在普通对象里，obj.key = undefined 会留下一个值为 undefined 的自有属性，只有 delete obj.key 才会移除属性。process.env 更容易误导，因为读到的都是字符串，开发者可能把它当作配置字典来做类型化赋值。Node.js 对环境变量属性的非字符串赋值会转成字符串；这个隐式转换已被标记为弃用方向，代码不应依赖它长期保留。
下面用一个独有的环境变量名先写入普通字符串，再赋 undefined，随后执行 delete。输出能区分键是否还在，以及读到的内容和类型。完整脚本在 tools/verify-node-process-env-20261027.mjs，日志在同名 .log。
assigned string: value=ready type=string
assigned undefined: exists=true value="undefined" type=string
after delete: exists=false value=undefined
赋值后，Object.hasOwn(process.env, key) 仍为 true，读值是字符串 "undefined"。这和未设置有本质差异：条件 if (process.env[key]) 会把它当成真值，传给另一个函数时也不会自动恢复为 JavaScript 的 undefined。只有 delete process.env[key] 才让键从映射中消失。
缺省判断应在配置边界完成
如果某项变量可选，常见写法是 const mode = process.env.MODE || 'normal'。这里空字符串和缺失都会走默认值，但字面字符串 "undefined" 不会。?? 也解决不了这个问题，因为它只在 null 或 JavaScript undefined 时采用右侧值。环境变量在读入时已是字符串，检查应针对字符串规则，而不是假定任意类型都能自然转回缺失状态。
const rawMode = process.env.MODE
const mode = rawMode === undefined || rawMode === '' ? 'normal' : rawMode
若空字符串本身有意义，默认逻辑应只比较 undefined；若空串等同于未配置，才把两者放在同一分支。这个差别属于应用自己的配置契约，不能交给 || 猜。数值等字段也应在边界显式解析，解析失败时给出明确错误，而不是先对 process.env 写入非字符串值再期待它保存原类型。
删除只影响当前进程的映射
删除只清理当前 process.env 映射，检查值是否为 undefined 则只是在读路径上判断，两者不能替代。若启动时已读取成常量，后来执行 delete 不会自动更新那个常量；下一次直接读取 process.env.NAME 才能看到映射变化。多处代码各自缓存配置时，应统一在启动边界解析，避免局部删除后仍有旧值被继续使用。
还有一个实际风险：环境变量有时包含凭据。将键赋为 undefined 以为删除，后续的日志或配置转储却可能把 "undefined" 继续带下去。测试中使用唯一的临时名称，并在 finally 里删除，避免给当前进程留下状态。本实验只检查 Node 进程中的读写语义，没有验证 shell 的导出状态或不同操作系统的环境实现。
这类值转换发生在写入那一刻，后续读取已经看不到原来的类型。若输入先经过配置校验再落到业务变量，校验逻辑能保留缺失与字符串值的区别；若先写进环境映射，后面的代码只能看到转换后的内容。把赋值和删除分成两条明确路径，测试里也能直接断言两种状态。配置入口最好把原始字符串读取一次，再把解析后的值交给业务代码；这样业务函数不必重复猜测环境变量是否缺失，也不会把环境映射当作可变状态仓库。我会避免用赋 undefined 做清理，因为代码表面上很像常规对象赋值，结果却留下一个非空字符串。
Node.js 26.8.1 本机输出确认，赋 undefined 后属性仍存在，值的类型是 string；删除后属性不存在。弃用警告是否显示取决于执行方式和警告配置，不应把警告当作判断逻辑。需要清掉当前进程的变量就用 delete，选择默认值时则要分别约定缺失与空字符串的含义。
