Commander 全局选项值来自父命令，来源却显示 cli

子命令读取到的选项值来自父命令，来源查询却说是 cli。若父命令用 setOptionValue() 写入同名值，而子命令又从命令行得到这个选项，Commander 的值合并与来源合并可能没有对齐。

这个问题只影响返回的来源信息，不代表父命令的值没有生效。正式 Commander 15.0.0 的 optsWithGlobals() 与 getOptionValueSourceWithGlobals() 保留了不同的覆盖条件，需要一起检查。

值被覆盖了，来源却跳过 undefined

下面是独立的 ESM 配置与解析示例，使用 Commander 15.0.0 时，Node 需满足其 >=22.12.0 要求：

import { Command } from 'commander';

const program = new Command()
  .enablePositionalOptions()
  .option('--common <value>')
  .setOptionValue('common', 'parent');

const sub = program
  .command('sub')
  .option('--common <value>')
  .action(() => {});

program.parse(['sub', '--common', 'child'], { from: 'user' });

const value = sub.optsWithGlobals().common;
const source = sub.getOptionValueSourceWithGlobals('common');

optsWithGlobals() 让祖先命令覆盖子命令，所以最终 value 为 parent。setOptionValue() 写入父值时又把来源设为 undefined；来源查询遍历祖先时跳过 undefined，可能留下子命令的 cli。两次查询于是描述了不同层级的值。

如果应用根据 source 决定是否打印“用户显式指定”、保存配置或覆盖别的设置，这个差异就可能影响后续分支。不要仅凭来源返回 cli，就把 parent 当成用户在子命令中输入的值。

程序注入配置时，同时标明真实来源

如果 parent 确实来自应用读取的配置，可以在原写入入口使用公开的来源 setter：

program.setOptionValueWithSource('common', configValue, 'config');

configValue 是已经按应用规则读取并校验的值。这样父值与 config 来源可以一起参与全局覆盖；若值来自环境或别的约定，应记录它真实的来源，不要为了得到某个预期字符串伪装成 cli。

必须保留“来源未知”的业务语义时，不应硬填一个来源掩盖差异。可避免父子重用同一个选项名称，或在自己的配置合并层把有效值和来源作为一对处理，明确哪个命令最终拥有该值。不要用 source || 'default' 推断缺省：undefined 可能是程序写入时有意清掉来源，与默认值不是同一回事。

这一处理也不会替你改变父子选项的优先级。若产品本来希望子命令覆盖全局值，应重新设计选项合并约定，而不是只修来源标签。

按有效值与来源成对验证

检查只有父值、只有子命令 CLI 值、两者同名，以及父值通过带来源 setter 写入的情况。同时保留真实启动参数，尤其是启用 positional options 后全局选项的位置规则。

截至 2026 年 10 月 25 日，正式 15.0.0 的来源查找仍跳过 undefined。后续升级时，既要看查询得到的 source，也要看 optsWithGlobals 的有效值，不应只以来源字符串变了作为恢复标准。应用依赖这组结果的配置保存和优先级判断也要一起回查。