你遇到的这个问题确实是DevSecOps领域里供应链安全的典型痛点——明明想靠锁文件规避恶意包，结果更新顶层依赖时子依赖会跟着被语义化版本规则拉取最新补丁，反而给恶意包留了空子。结合我做Node.js项目安全的实际经验，给你几个落地性强的解决方案：

一、强制锁定所有子依赖的精确版本 #

如果想彻底把子依赖版本焊死，不让它随便变动，有两个实用的方法：

1. 用resolutions字段强制指定子依赖版本
   npm、yarn、pnpm都支持在package.json里添加resolutions字段，直接指定某个子依赖的精确版本，不管顶层依赖要求的版本范围是什么。比如：

   {
     "resolutions": {
       // 锁定所有依赖树里的lodash为4.17.21
       "lodash": "4.17.21",
       // 锁定any-package的所有子依赖里的sub-dep为1.2.3
       "any-package/**/sub-dep": "1.2.3"
     }
   }
   

   添加后执行npm install或pnpm install，包管理器就会严格按照你指定的版本安装子依赖，更新顶层依赖时也不会覆盖这个设置。

2. 用npm ci/pnpm --frozen-lockfile严格遵循锁文件
   如果你已经通过npm install生成了包含精确子依赖版本的package-lock.json，后续部署或安装时别用npm install，改用npm ci——它会完全按照锁文件的版本安装，不会因为语义化版本规则拉取新的子依赖。pnpm则可以用pnpm install --frozen-lockfile达到同样的效果。

二、让依赖更新工具管控子依赖的版本年龄 #

你提到的Renovate和Dependabot其实都能管控子依赖的更新年龄，只是需要针对性配置：

针对Renovate #

在renovate.json里开启lockFileMaintenance，并设置版本最小发布年龄，这样它在更新锁文件里的子依赖时，只会挑选发布够天数的版本：

{
  "lockFileMaintenance": {
    "enabled": true,
    // 只选发布超过7天的版本
    "minimumReleaseAge": "7 days"
  },
  // 可选：设置只更新锁文件，不修改package.json的顶层依赖版本
  "rangeStrategy": "lockfile-only"
}

针对Dependabot #

在.github/dependabot.yml里添加constraints配置，同时用lockfile-only策略只更新锁文件：

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # 只更新锁文件，不改动package.json的版本范围
    versioning-strategy: "lockfile-only"
    constraints:
      # 要求版本发布至少7天才能被更新
      minimum_release_age: "7 days"

这样工具在维护子依赖版本时，会自动过滤掉刚发布的版本，降低踩恶意包的风险。

三、换用更严格的包管理器 #

pnpm和Yarn Berry（Yarn 2+）的锁文件机制比npm更严谨，天生更适合管控子依赖：

• pnpm：它的pnpm-lock.yaml会记录每个子依赖的精确版本和来源，默认情况下更新顶层依赖时不会随意升级子依赖，除非你明确指定。而且它的依赖隔离机制能避免子依赖被意外共享升级。
• Yarn Berry：支持更强大的resolutions配置，还有yarn up命令可以精确更新单个子依赖，比如yarn up sub-dep@1.2.3直接锁定子依赖版本，操作更灵活。

四、轻量验证工具替代私有仓库 #

如果搭建私有npm仓库成本太高，可以用一些轻量工具辅助验证子依赖：

• 用lockfile-lint检查锁文件里的版本是否符合你的规则（比如版本发布时间、是否是精确版本），可以集成到CI流程里，不符合就阻断构建。
• 写个简单的Node脚本，用npm view <package> time接口获取版本发布时间，过滤掉发布时间不足X天的版本，再配合npm update更新子依赖。

对你疑问的直接解答 #

1. 有没有固定子依赖的方案？
   有，resolutions字段+npm ci/pnpm的冻结锁文件方案，能彻底固定子依赖版本；换用pnpm/Yarn Berry也能大幅降低子依赖意外升级的概率。

2. 有没有按最小年龄更新子依赖的方案？
   有，通过Renovate的lockFileMaintenance或Dependabot的minimum_release_age配置，就能让工具只更新发布够天数的子依赖版本，不用手动筛选。

最后提个小建议：如果是中小项目，用resolutions+Renovate的锁文件维护配置就能解决大部分问题；如果是大型项目，建议换成pnpm，再配合供应链安全扫描工具做兜底，安全层级会更完善。