composer.lock 默认不存密码或API Key，仅记录包信息和URL；但若在composer.json中硬编码含密钥的私有仓库URL（如token@host），该URL会被原样写入lock文件。
composer.lock 里会不会存密码或 API Key？
不会。默认情况下，composer.lock 只记录包名、版本、哈希值、依赖关系和自动解析出的安装路径（如 dist.url），**不保存任何认证凭据**。你配置在 auth.json 或环境变量里的 token、username/password，根本不会进 lock 文件。
但问题常出在「人」：比如把含密钥的私有仓库 URL 直接写进 composer.json 的 repositories 里——这种 URL 会被原样记入 composer.lock。
-
"url": "https://token:abc123@packages.example.com"→ 锁文件里就真有abc123 -
"url": "git@github.com:org/private-package.git"→ 一般安全，但若配了带密钥的 SSH URL（如ssh://user:pass@...）也会泄露
如何安全地配置私有包源？
用 Composer 官方推荐的 auth.json 机制，把凭证和代码分离。它支持按域名分级配置，且默认被 .gitignore 排除。
实操建议：
- 在项目根目录创建
auth.json，内容类似：{ "http-basic": { "packages.example.com": { "username": "myuser", "password": "env:COMPOSER_REPO_TOKEN" } } } - 把
COMPOSER_REPO_TOKEN设为 CI 环境变量或本地 shell 变量，避免硬编码 - 确保
auth.json在.gitignore里 —— Composer 初始化时会提示，但很多人手动生成就忘了 - 别用
config.platform或extra字段塞敏感值，它们可能被插件读取并间接暴露
检查 lock 文件是否已泄露敏感信息
直接搜。composer.lock 是 JSON，结构固定，重点盯两个字段：dist.url 和 source.url。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
执行这条命令快速排查：
grep -E '"(dist|source)":{"url":"' composer.lock | grep -E '[@:/?&=]' | grep -v 'github.com\|gitlab.com\|bitbucket.org'
说明：
- 匹配到非主流 Git 托管平台的 URL，尤其含
@（用户密码分隔符）或?/&（常见于 token 参数）就要人工确认 - GitHub/GitLab 等标准地址通常安全；但
https://x-access-token:abc...@gitlab.example.com就是高危信号 - 如果已提交，不能只删 lock 文件重生成——得先清理 Git 历史（用
git filter-repo），否则旧 commit 还藏着密钥
CI/CD 中生成 lock 文件的注意事项
CI 环境里运行 composer install 或 update 时，如果用了临时凭据（比如 GitHub Actions 的 ${{ secrets.TOKEN }}），这些凭据本身不会进 lock，但可能导致锁文件记录下「本不该出现的」分支快照或 dev 版本。
更隐蔽的风险点：
- CI 脚本里用
composer config repositories.xxx.url "https://$TOKEN@..."动态添加源 →$TOKEN会拼进 URL 并写入 lock - 用
--with-all-dependencies或--dry-run不影响 lock，但composer update --lock会强制重写，可能覆盖掉你手动清理过的 URL - 建议在 CI 中始终用
composer install --no-interaction，而非update，避免意外触发解析逻辑
真正难防的不是 lock 文件本身，而是开发时图省事把凭证揉进 URL 的惯性操作。一旦进 Git，删 lock 文件没用，得清历史——这事容易拖到审计临门一脚才处理。
