应调process-timeout，因其控制git clone、unzip、post-install-cmd等子进程执行时限，默认300秒，CI中大项目易触发；http.timeout仅影响HTTP下载阶段，卡在“Executing command”时无效。
CI里报ProcessTimedOutException，该调哪个timeout
调 process-timeout，不是 http.timeout。错误信息里明确含 The process "" exceeded the timeout，说明是 git clone、unzip 或自定义脚本这类子进程被杀，和 HTTP 下载无关。
process-timeout 控制整个命令生命周期（含解压、生成 autoload、执行 post-install-cmd），默认仅 300 秒；大项目或低配 runner 很容易触发。而 http.timeout 只管单次 HTTP 请求（比如拉 packages.json），卡在 Downloading https:// 才轮到它。
- 设为
1200（20 分钟）较稳妥，600（10 分钟）可作底线 - 环境变量
COMPOSER_PROCESS_TIMEOUT优先级最高，比composer config -g更可靠 - 设为
0表示禁用超时，但不推荐：某条git clone卡死会导致 job 无限挂起
GitHub Actions中怎么设才真正生效
别依赖 composer config -g 写配置文件——容器每次启动都重置，且可能没写入权限。直接用环境变量最稳：
- GitHub Actions 中，在
steps里加：env: { COMPOSER_PROCESS_TIMEOUT: "1800" } - GitLab CI 中，在
variables下加：COMPOSER_PROCESS_TIMEOUT: "1800" - Docker 环境要确认外层没被
timeout命令或docker run --stop-timeout截断
顺带一提：COMPOSER_HOME 也得显式设（比如 /tmp/composer），否则缓存路径可能落在只读层，导致后续操作失败。
Git post-commit 钩子 + SQLite 提交索引工具。自动将每次提交的元数据（哈希值、作者、分支、仓库、主题）记录到本地 SQLite 数据库中，随后提供一个命令行接口（CLI），支持查询、列表展示、统计、删除和更新记录。 触发场景：管理 Git 钩子、跨仓库查询提交历史、定位某次提交所属的仓库、查看提交统计信息、将提交记录写入本地索引。 当用户提及“提交日志记录”、“提交索引”、“跨仓库查找提交”、“Git 钩子管理”，或希望以结构化方式查询其提交历史时（即使未明确指出该工具），请使
为什么设了还超时？常见漏点
多数“设了还超时”不是参数没生效，而是被其他层级的限制截断了：
- PHP 的
max_execution_time被disable_functions禁用，导致set_time_limit()报错——CI 镜像常默认禁用它 -
memory_limit不足（尤其composer update解析锁文件时），会先 OOM 再被误判为超时；建议 ≥ 1.5G - CI runner 的系统级硬限制（如某些自建 runner 设了 20 分钟 timeout）比 Composer 超时更早触发
- 用了
--no-dev，但脚本里又调了phpstan这类 dev-only 工具，实际根本没装上，脚本执行失败被当成超时
自定义脚本（如post-install-cmd）超时怎么办
这类脚本由 PHP 进程直接执行，受 PHP 的 max_execution_time 控制，和 process-timeout 无关。不能在 composer.json 的 config 段加 timeout 字段——那字段只对 HTTP 生效。
- 临时方案：
php -d max_execution_time=0 composer install，强制 PHP 不中断 - 长期方案：在脚本入口处手动调
set_time_limit(0)，但必须放在逻辑最前面，否则可能被后续代码覆盖 - CI 中推荐统一用
php -d max_execution_time=900，避免依赖系统默认值（常是 30 秒）
真正麻烦的是 autoload 生成阶段卡住——它既不受 process-timeout 管，也不听 max_execution_time，而是被文件系统 I/O 或 symlink 解析拖慢，比如 WSL2 或 Docker for Mac 下的 NTFS 挂载卷。
