PM2 filter_env 为 true，应用为什么仍继承终端变量

ecosystem 配置写了 filter_env: true，应用却仍能读到部署终端里的环境变量。若使用 PM2 7.0.4 或当前正式 7.1.1，先检查环境合并路径，别把这个布尔值当成已经生效的完整隔离。

这些版本的 Common.js 先判断 filter_env 是否有非零 length，满足才调用过滤函数。true 的 length 是 undefined，因此没有进入过滤；过滤函数内部虽然有处理 true 的分支，也不会被这次调用走到。

显式 env 会覆盖同名值，不会自动拒绝其他变量

配置中的 env 对象随后合并到继承环境上。只写 env: { NODE_ENV: 'production' }，并不表示应用只获得 NODE_ENV。没有同名覆盖的终端变量，仍可能进入新进程。

先核对配置文件、实际启动入口、目标应用名称及环境来源。分享诊断时只记录必要变量名和是否存在，不打印整份 process.env；里面可能有认证信息、代理配置和其他应用的凭据。

如果某个 SDK 行为突然改变，还要检查它会读取哪些变量。仅删除应用代码中的显式参数，不能阻止 SDK 继续从环境中取得同名配置。

已知要排除哪些名字，可以采用局部数组规则

对明确知道的变量，可在新建的受控应用配置中使用数组形式。下面的名字用于演示过滤，不是完整的敏感变量清单：

module.exports = {
  apps: [{
    name: 'env-filter-check',
    script: './app.js',
    filter_env: ['LEAK_ME'],
    env: { NODE_ENV: 'production' },
  }],
};

7.1.1 的数组实现按变量名是否包含某个片段来排除，并不是严格相等匹配。LEAK_ME 也会匹配 PREFIX_LEAK_ME_SUFFIX；选择规则前检查会不会误删应用需要的名称。配置 env 中又显式提供的同名值，还可能在后续合并中重新加入，应一起核对。

数组名单只能排除已知项目，不能实现“仅允许这几个变量”的完整白名单。如果应用要求严格环境边界，应在原部署流程中给启动入口构造明确的环境集合，保留所需 PATH、HOME、证书、代理和运行配置，不能直接清空后再逐项猜缺什么。

已运行的进程需要单独安排替换

reload --update-env 的合并行为不保证删除旧环境项。修改启动终端或配置以后，只检查同一个旧进程的值，可能继续看到历史继承结果；反过来，新建测试应用通过，也不代表线上旧实例已经完成替换。

先保存现有配置和状态，按应用批准的滚动替换流程处理已有实例，核对进程身份、启动时刻与必要变量是否存在。不要为清环境执行 pm2 delete all、清空整个 PM2_HOME 或杀掉共享 daemon，其他应用可能也由它管理。

验收同时包含需要被排除的变量、应用必须保留的变量和多副本状态。对认证信息只确认来源与是否存在，不把值写入公开日志。若旧环境已使应用访问了错误的外部地址，代码和进程替换不会撤销那些请求，应另行核对业务结果与凭据处理。