composer.lock不是文本配置文件，而是带完整哈希校验的二进制快照，修改空格、删逗号或脚本patch均会导致install失败或退化为update行为；提交前须运行composer validate --strict，并禁用Git换行转换。
composer.lock 被部分修改或拼接会导致 install 失败
它不是文本配置文件，而是带完整哈希校验的二进制快照。哪怕改一个空格、删一个 trailing comma、或用脚本 patch 某几行，composer install 就可能直接拒绝执行，或退化为 composer update 行为——这不是警告，是硬性校验失败。
常见现象：Your lock file does not contain a compatible set of packages；本地能装，CI 构建时报 Package foo/bar has a PHP requirement incompatible with your PHP version（实际是 platform 字段被编辑器删了逗号导致 JSON 解析不全）。
- 提交前必须运行
composer validate --strict，检查语法+字段完整性 - Git 配置禁用换行转换：
git config core.autocrlf false，避免 Windows 编辑器污染 - 禁止在 CI 脚本中跑
composer update --lock后不提交——这等于把某次构建的临时结果当成了权威快照
换镜像源后 vendor/ 目录不可复用
镜像切换（比如从 packagist.org 切到阿里云）不改变 composer.lock 内容，但会改变 dist URL、缓存路径和平台相关产物。直接保留 vendor/ 会导致类加载失败、符号链接 dangling、ext 编译产物错位等静默故障。
根本原因：vendor/autoload.php 是根据当前 lock + 当前平台生成的静态映射；本地开发包（"type": "path"）的 symlink 指向原机器路径；某些扩展（如 ext-protobuf）的 .so 文件写死在 vendor/ 子目录里。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 每次镜像变更后，先执行
rm -rf vendor composer.lock，再composer install - Docker 构建必须用多阶段：builder 阶段用完整镜像源 +
--no-dev --optimize-autoloader，final 阶段只COPY vendor/和代码 - CI 脚本加防护：运行
composer config --list | grep repositories，输出不匹配预期镜像 URL 就abort
强制获取镜像站最新包的三步实操法
composer update 卡住或提示 “Nothing to install or update”，往往不是网络问题，而是 Composer 复用了本地缓存的 packages.json（默认 15 分钟不过期），压根没看到镜像站已上线的新版本。
只跑 composer clear-cache 不够——它只清 ZIP 包，不清元数据；只删 vendor/ 更没用，因为解析逻辑全靠 cache/repo/ 下的 provider 文件。
- 运行
composer update --refresh（Composer ≥ 2.5）：强制丢弃cache/repo/下所有元数据，从当前镜像源重拉packages.json - 立即跟
composer update vendor/package，此时才能识别镜像站刚同步的新版（如monolog/monolog:3.6.0） - 若需验证是否真走网络下载：加
-vvv参数，终端必须出现Downloading https://mirrors.aliyun.com/composer/...且时间戳是当前秒级
CI 流水线中 lock 文件 hash 漂移的根源与规避
不同 CI 节点用了不同镜像源（A 节点用阿里云，B 节点用腾讯云），而两个镜像同步延迟不一致，就会拉到不同时间点的 packages.json 快照，导致依赖解析微差，最终 composer.lock 的 hash 变动——这不是 bug，是镜像行为差异的必然结果。
镜像源只影响下载速度，不影响包内容本身，但元数据快照不一致，就足以让 Composer 解出不同依赖树。
- 所有 CI 节点必须统一用同一镜像源，推荐腾讯云：它对未命中包会自动 fallback 到
packagist.org，行为最接近官方源 - 禁止项目级
repositories配置，它会完全屏蔽全局设置，极易在 CI 中漏配 - 每次构建开头显式校验：
composer config -g repo.packagist输出必须是目标镜像 URL，否则中断
composer.lock 完整性、vendor/ 目录清空策略、元数据刷新时机、以及 CI 环境一致性四者咬合而成。漏掉任意一环，都可能在看似成功的部署后，埋下 runtime 类找不到或版本错乱的隐患。 
