Composer镜像同步服务不依赖MySQL长连接，所谓MySQL超时实为HTTP/TLS/TCP层问题；错误源于同步脚本中PDO持久连接闲置超时未重连，应禁用持久连接、启用异常捕获并重建连接。
Composer 镜像同步服务本身不依赖 MySQL 长连接，它跑在 HTTP/HTTPS 层，和数据库无关；所谓“MySQL 长连接超时断开”是误判——真正卡住的是 Composer 自身的 HTTP 连接、TLS 握手或底层 TCP 链路，不是 MySQL。
为什么镜像同步日志里出现 MySQL 超时错误？
常见现象是同步脚本（比如用 PHP 写的镜像爬虫）报 MySQL server has gone away 或 Lost connection to MySQL server during query。这不是 Composer 的问题，而是你写的同步服务代码里混用了长连接 + 闲置超时未重连。
- MySQL 的
wait_timeout默认通常为 28800 秒（8 小时），但很多内网环境或云 RDS 实际设为 300～600 秒 - 同步服务若用 PDO 持久连接（
PDO::ATTR_PERSISTENT => true）且长时间没发查询，连接会被 MySQL 主动断开 - 后续再执行
$pdo->query()就触发错误，而日志里紧挨着 Composer 下载日志，容易被误认为是镜像源问题
同步服务里怎么安全用 MySQL 连接？
别指望靠调大 wait_timeout 解决——运维侧改全局配置风险高，且治标不治本。关键是让 PHP 代码自己处理连接生命周期：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 禁用持久连接：
PDO::ATTR_PERSISTENT => false，每次操作新建连接，简单可靠 - 启用自动重连：
PDO::ATTR_EMULATE_PREPARES => true和PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"不够，得加PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，捕获SQLSTATE[HY000] [2006]后重建 PDO 实例 - 写个轻量连接包装器：每次查库前先
$pdo->getAttribute(PDO::ATTR_CONNECTION_STATUS)，失败就new PDO(...)，比 try/catch 更早感知 - 如果用 Laravel Scout 或自研队列驱动，确认
DB_RECONNECT环境变量已开，避免队列进程空闲时连接失效
Composer 配置里根本没 MySQL 参数
所有 composer config 命令只影响 HTTP 请求行为（如 http.timeout）、包安装策略（如 preferred-install）或源地址（如 repos.packagist.org）。MySQL 相关参数完全不在 Composer 控制范围内：
-
mysql.default_socket是 PHP ini 设置，Composer 不读 -
wait_timeout、interactive_timeout是 MySQL 服务端变量，改了也只对新连接生效 - 你在
composer.json里写"mysql": {"host": "..."}不会起任何作用——Composer 解析时直接忽略
真要让镜像同步稳，盯住三件事：换阿里云/腾讯云镜像源、调 http.timeout 到 600、同步脚本里别复用失效的 PDO 连接。后者最容易被忽略，因为错误堆栈总出现在“插入 metadata”那一行，让人以为是数据太大会卡住。
