因为composer是php脚本，实际由php解释器执行，strace默认只跟踪外层shell命令，无法捕获php进程内部的系统调用；必须显式用strace -f追踪php /usr/bin/composer install才能完整捕获文件、网络等关键行为。
为什么直接 strace composer install 会失败
因为 composer 是 PHP 脚本，实际执行的是 php 解释器调用，strace 默认只跟踪外层 shell 命令，不会进入 PHP 进程内部。直接运行 strace composer install 只能看到 shell 启动 php 的那几行 fork/exec，后续所有文件操作、网络请求都丢失。
必须显式调用 PHP 解释器并传入 Composer PHAR 文件路径，才能真正捕获其系统调用行为：
strace -f -e trace=openat,read,write,connect,sendto,recvfrom -s 256 -o composer.strace php /usr/bin/composer install-
/usr/bin/composer是典型安装路径，需替换为which composer实际输出 -
-f必须加——Composer 内部会 fork 子进程执行 git、curl 等命令，不加就看不到这些关键调用 -
-s 256防止路径被截断（比如/home/user/project/vendor/composer/installed.json被砍成/home/user/project/vendor/composer/inst...）
如何精准捕获 Composer 的文件探测行为
Composer 在 autoload、classmap 生成、依赖解析阶段会大量调用 openat 和 stat 探测文件是否存在。默认 strace 不显示 stat 类调用，容易误判“没读配置”。
应强制包含全部文件相关系统调用：
-
-e trace=openat,open,stat,fstatat,access——access是判断权限的关键调用，漏掉可能看不出为什么跳过某个autoload目录 -
openat比open更重要：现代 Composer 大量使用相对路径 +AT_FDCWD，只抓open会漏掉 70%+ 的真实文件访问 - 若怀疑 Composer 读取了不该读的敏感路径（如
/root/.ssh/config），在输出中搜openat.*\/root\/\.ssh或stat.*\/etc\/shadow
抓网络请求时为什么看不到 HTTPS 握手细节
strace 只能追踪到 socket 层，抓不到 TLS 加密内容。它能看到 connect、sendto、recvfrom，但无法区分 HTTP/1.1 和 HTTPS 流量，更看不到证书验证过程。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
实际调试时要注意：
-
connect(3, {sa_family=AF_INET, sin_port=htons(443), ...}) = 0表示成功连上 HTTPS 端口，不代表 TLS 握手成功 - 若看到
sendto后紧接recvfrom返回EAGAIN或EWOULDBLOCK，说明底层 SSL 库正在做非阻塞 I/O，不是网络问题 - 真正卡住的位置往往在
read系统调用上——比如 Composer 卡在read(3, ...)，说明远程服务没返回数据，而非 DNS 或连接失败 - 要确认是否 TLS 问题，得配合
openssl s_client -connect repo.packagist.org:443 -servername repo.packagist.org单独验证
strace 输出里哪些返回值代表 Composer 真正失败了
不是所有 -1 都是错误：PHP 层会主动调用 stat 判断文件是否存在，stat("vendor/autoload.php", ...) = -1 ENOENT 是正常流程；但 openat(AT_FDCWD, "composer.json", O_RDONLY) = -1 EACCES 就是权限问题。
重点关注这几类失败模式：
-
EACCES或EPERM：当前用户无权读取composer.json、写入vendor/，或无法执行git（常见于容器内 UID 不匹配） -
ENOTDIR：路径某一级是文件而非目录，比如mkdir -p vendor && touch vendor后再运行 install，openat会在此处失败 -
ETIMEDOUT或ECONNREFUSED：出现在connect调用后，说明网络不通或镜像源不可达 -
EMFILE：打开文件数超限，常见于并发composer update+ 大量依赖，需检查ulimit -n
最易被忽略的是 openat 成功但后续 read 返回 0 字节——这通常意味着 Composer 打开了一个空文件（如损坏的 composer.lock），却没报错，而是静默跳过解析，最终导致依赖版本混乱。
