本质是i/o延迟导致系统调用阻塞，使php计时器持续运行超时；常见于nfs/smb/docker挂载等场景；可通过microtime日志和strace定位阻塞点；推荐异步落盘+超时兜底策略。
PHP写入文件时卡住或报错“Maximum execution time exceeded”
本质是脚本执行时间超出了 max_execution_time 限制，而文件写入（尤其是大文件、网络存储、NFS、挂载盘）可能因 I/O 延迟意外阻塞。不是 PHP 写操作本身慢，而是底层系统调用被挂起，PHP 线程无法继续，计时器照常走。
- 常见于使用
fopen()+fwrite()写入 SMB/NFS 共享目录、Docker 挂载卷、云存储网关等场景 -
file_put_contents()同样受此影响，它底层也调用同步写入系统 API - 即使磁盘空闲，若目标路径响应延迟高（如远程 CIFS 挂载掉包），
fopen()可能卡在 open(2) 系统调用上，直接耗尽超时时间
如何判断是不是 I/O 阻塞导致的超时
别只看错误信息——Maximum execution time of X seconds exceeded 是表象，关键要确认是否真卡在写入环节。最直接的方式是加日志和信号捕获：
- 在
fopen()前后打microtime(true)日志，确认耗时是否集中在打开阶段 - Linux 下可配合
strace -p $(pidof php) -e trace=open,write,fsync观察系统调用是否长时间无返回 - 如果
fopen()成功但fwrite()卡住，大概率是 write(2) 被阻塞（例如 ext4 日志模式 + 磁盘满、NFS server hang）
绕过超时的实用写法：异步落盘 + 超时兜底
PHP 本身不支持真正的异步文件 I/O，但可通过分离「接收」和「落盘」降低风险。核心思路是：先收数据进内存/临时缓存，再用非阻塞方式交由后台处理。
- 小文件（file_put_contents($path, $data, LOCK_EX)，避免手动 fopen/fwrite 的中间状态；加上
LOCK_EX减少并发冲突引发的隐式等待 - 中大文件：写入前先用
is_writable($path)+disk_free_space($path)快速探活，失败立刻返回，不进写逻辑 - 高可靠场景：把内容写入
/tmp（本地磁盘），再用pcntl_fork()或队列（如 Redis List + worker）异步 mv 到目标路径——主流程不承担 I/O 风险
必须调整的三个 PHP 配置项
仅靠代码规避不够，底层配置没调对，问题还会复现。重点不是盲目加大 max_execution_time，而是让超时更合理：
立即学习“PHP免费学习笔记（深入）”；
-
max_execution_time = 30保持默认，但对已知慢写入路径，用set_time_limit(0)**仅限该段逻辑**，用完立刻set_time_limit(30)恢复，防失控 -
default_socket_timeout = 5影响 FTP、HTTP 流写入，若用file_put_contents("ftp://...")必须调低，否则 socket connect/write 会吃掉全部超时时间 -
output_buffering = 4096或更高，避免频繁 flush 触发底层 write，尤其搭配ob_start()时——buffer 不足会导致每行都 syscall
真正麻烦的是那些看似“只是写个日志”的地方：比如 error_log() 指向 syslog，而 rsyslog 正在重启；或者 session.save_path 设在 NFS 上，恰好服务器负载高。这些路径不会报错，但会让整个请求卡住几秒甚至几十秒——没人会去查 session 存储的 I/O 健康度。
