根本原因是PHP脚本未处理网络异常与硬件重连，而非PHP自身断连；应通过shell探测网络、PHP专注硬件控制，并用systemd实现毫秒级响应与权限管理。
PHP 嵌入式设备断网后无法自动恢复控制？根本原因不是 PHP 本身
PHP 是服务端脚本语言，运行在嵌入式 Linux（如树莓派、OpenWrt 设备）上时，php 进程本身不维持网络连接状态，也不直接管理硬件 GPIO/串口。所谓“断网后无法恢复控制”，实际是：网络中断导致 PHP 脚本依赖的通信链路（如 MQTT 订阅、HTTP 长轮询、串口 /dev/ttyUSB0 被占用或丢失）失效，且脚本未做异常捕获与重试 —— 不是 PHP “断连了”，而是你写的控制逻辑没应对网络抖动。
如何检测网络是否恢复并触发硬件重连？用 shell + PHP 协同判断
纯 PHP 的 fsockopen() 或 curl_exec() 在后台常驻运行不可靠（易被 SIGTERM 终止、无守护机制）。推荐用轻量级 shell 脚本做网络探测，PHP 只负责执行具体硬件操作：
- 用
ping -c1 -W2 8.8.8.8判断基础连通性（避免 DNS 依赖，直连 IP） - 加
grep "1 received"精确匹配成功包（防止超时但返回空行误判） - 网络恢复后，用
php /path/to/hw_control.php启动控制逻辑（不要让 PHP 自己死循环 ping） - 务必在
hw_control.php开头加ignore_user_abort(true)和set_time_limit(0)，防止 Web 请求中断影响后台执行
#!/bin/sh
while true; do
if ping -c1 -W2 8.8.8.8 | grep "1 received" > /dev/null; then
echo "$(date): network up, restarting control"
php /opt/app/hw_control.php &
break
fi
sleep 5
done
PHP 控制硬件时遇到 “Permission denied” 或 “No such file” 怎么办？
断网重启后常见现象：串口设备节点消失（/dev/ttyUSB0 重插后变成 /dev/ttyUSB1），或用户无权限访问 GPIO（/sys/class/gpio/export 拒绝写入）。不能硬编码路径或假设权限已存在：
- 用
glob("/dev/ttyUSB*")动态查找可用串口，取第一个非空结果 - GPIO 操作前先检查
file_exists("/sys/class/gpio/gpio17/value")，不存在则执行shell_exec("echo 17 > /sys/class/gpio/export 2>/dev/null") - 确保运行 PHP 的用户（如
www-data）在dialout（串口）和gpio（GPIO）组中：usermod -a -G dialout,gpio www-data - 串口打开失败时，用
stream_get_meta_data($fp)查看timed_out或blocked状态，而非只捕获false
为什么用 systemd 服务比 crontab 更适合嵌入式重连？
crontab 每分钟检查一次网络，延迟高、资源浪费；systemd 可监听网络接口状态变化，毫秒级响应。关键配置点：
立即学习“PHP免费学习笔记（深入）”；
- 写一个
/etc/systemd/system/net-recover.service，Type=oneshot，ExecStart=/usr/local/bin/check-and-restart.sh - 加
WantedBy=network-online.target，确保仅在网络真正就绪后触发 - 禁用默认的
NetworkManager-wait-online.service（OpenWrt 等精简系统可能没有），改用systemd-networkd-wait-online.service - 启动后用
systemctl status net-recover看日志，错误会直接显示在journalctl -u net-recover中
最易忽略的是：systemd 默认限制脚本访问 /sys 和 /dev，需在 service 文件里显式加 ReadWritePaths=/sys/class/gpio /dev/ttyUSB*。
