php调用python脚本被强制中断主因是max_execution_time超时导致子进程被连带终止，需在php中set_time_limit(0)、调整php-fpm和nginx超时参数（如fastcgi_read_timeout），或改用nohup后台执行、消息队列异步解耦。
PHP调用Python脚本时被强制中断？先看是不是max_execution_time在作怪
PHP默认的max_execution_time（通常30秒）会限制整个脚本生命周期，哪怕你用exec()或shell_exec()启动了Python进程，PHP主进程超时后会直接杀掉子进程——这是最常被忽略的根源。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在PHP脚本开头加
set_time_limit(0)，禁用PHP层超时（注意：CLI模式下默认不限时，但Web服务器如Apache/PHP-FPM可能另有约束） - 检查
php.ini中max_execution_time和max_input_time，若为生产环境，建议只在必要脚本中动态调整，而非全局改大 - FPM环境下还需确认
request_terminate_timeout（php-fpm.conf）和request_slowlog_timeout，这两个值可能比PHP设置更早触发终止
Python子进程被PHP“连坐”杀死？用nohup或disown脱离父进程关系
PHP调用exec("python script.py")时，Python进程是PHP的子进程；PHP超时退出，系统通常会向整个进程组发送SIGTERM。要真正“隐藏”执行，必须让Python脱离PHP的进程组控制。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- Web环境推荐：
exec("nohup python /path/to/script.py > /dev/null 2>&1 & echo $!")，nohup防止SIGHUP，&后台运行，echo $!可捕获PID用于后续状态检查 - 避免直接用
system()或passthru()，它们会同步等待，无法规避PHP超时 - 如果需返回结果，别依赖实时输出——改用Python脚本写结果到文件或数据库，PHP另起轮询或回调机制读取
PHP-FPM + Nginx场景下，光调PHP时间没用：还得调fastcgi_read_timeout
Nginx作为反向代理时，即使PHP脚本没超时，Nginx也会在fastcgi_read_timeout（默认60秒）后主动断开连接，导致前端看到504 Gateway Timeout，而PHP日志里却查不到错误。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在Nginx server或location块中显式设置：
fastcgi_read_timeout 300;（单位秒），并重载配置nginx -s reload - 同时确认
fastcgi_send_timeout和fastcgi_connect_timeout是否过小，尤其当Python需长时间初始化（如加载大模型）时 - 不建议无脑设为0（无限），应按业务最长合理耗时设定，避免连接堆积
想彻底解耦？别让PHP“等”Python，改用消息队列或异步任务
硬扛超时不是长久之计。真实业务中，Python任务往往涉及IO密集（爬虫、图像处理）或CPU密集（训练、推理），与PHP Web请求生命周期天然冲突。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 轻量级方案：PHP写任务到Redis队列（
RPUSH），用supervisord常驻Python worker监听并消费，完成后写回Redis或发通知 - 稍重一点：用
Beanstalkd或RabbitMQ，配合pheanstalk（PHP）和beanstalkc（Python）客户端 - 完全规避超时概念：前端提交后立即返回任务ID，后端用AJAX轮询
/api/task/status?id=xxx查进度——Python脚本只负责执行和存状态，不参与HTTP响应流
真正难的不是延长几秒钟，而是判断这个Python任务该不该由Web请求触发。IO/CPU耗时超过2–3秒，就该考虑异步化；否则再调参数也只是掩耳盗铃。
