自动化流水线不负责锁定依赖版本，只校验锁文件一致性、安装指定版本、确认变更受控；锁文件必须提交至Git，CI须用npm ci/composer install等命令严格按锁文件执行，禁止动态解析或更新依赖。
自动化流水线本身不负责“锁定”依赖版本，而是严格执行和验证已锁定的版本。真正的锁定动作发生在开发阶段（如提交 package-lock.json 或 composer.lock），流水线只做三件事：校验锁文件一致性、安装指定版本、确认变更受控。
锁文件必须纳入版本控制
这是所有后续自动化的前提。无论用 npm、Composer、pip 还是 Maven，生成的锁文件（如 package-lock.json、composer.lock、Pipfile.lock、mvn dependency:tree 验证后的 effective-pom）都需提交到 Git。流水线每次构建都基于这份“快照”，而非重新解析 package.json 或 composer.json。
- 禁止在 CI 中运行
npm install时不带 lock 文件，或运行composer update等重算依赖的命令 - Git 提交前应确保 lock 文件已更新（例如开发者执行
npm install后自动更新package-lock.json） - CI 可增加前置检查：运行
npm ci（而非npm install）——它只读 lock 文件，失败即终止
流水线中强制校验与安装
CI 不信任任何人工操作，每一步都要可验证。重点不是“怎么锁”，而是“是否真锁住了”。
- 对 Node.js 项目：用
npm ci --no-audit --no-fund，跳过 package.json 版本解析，直接按 lock 文件安装 - 对 PHP/Composer 项目：先
composer validate --strict检查 json 与 lock 是否匹配；再composer check-platform-reqs确认 PHP 和扩展满足要求；最后composer install --no-dev --optimize-autoloader --classmap-authoritative - 对 Python 项目：激活虚拟环境后执行
pip install --no-deps -r requirements.txt（若用 pip-tools）或pip-sync requirements.txt，确保只装 lock 文件指定版本
升级必须由人驱动、事件触发
流水线不主动升级，但要支持安全、可控的升级流程。升级不是定时任务，而是响应明确信号。
- 监听
composer.json修改：通过git diff --name-only HEAD~1 composer.json判断是否有人主动调整了依赖声明 - 响应安全告警：调用
composer audit --format=json（≥2.5），提取"severity": "critical"的包，仅对这些包执行composer update guzzlehttp/guzzle --with-dependencies - 适配平台变更：当 CI 检测到 PHP 升级，运行
composer outdated --direct --ignore=php，过滤掉不兼容项，再人工确认升级范围 - 每次升级后，必须检查
git diff --quiet composer.lock是否有变更——这是唯一可信的“本次是否真升级了”的依据
用插件或脚本防止意外绕过
再好的流程也防不住手误。需要用工具兜底，把“不该写的 version”拦在构建前。
- Maven 项目启用 Enforcer 插件：配置
banDuplicatePomDependencyVersions规则，禁止子模块在<dependency>中写<version> - Node.js 项目可在 CI 中加检查：
npm ls --depth=0 | grep -v "UNMET" || exit 1，确保顶层依赖与 package.json 完全一致 - Python 项目使用
pip-check或pipdeptree --warn stale，识别未锁定但实际安装了新版的包
