PHP进程崩溃前应通过原子文件写入（fopen 'c' 模式+临时文件+rename）、数据库事务（InnoDB）保障数据安全；UPS异常需主动探测upsc退出码，连续两次超时才降级；Web请求中断时设ignore_user_abort(false)并关闭output_buffering；关机逻辑应由nut-monitor等系统服务执行，PHP仅记录与通知。
PHP进程崩溃前如何安全保存关键数据
断电时PHP脚本会直接被系统终止，register_shutdown_function() 大概率来不及执行。真正能靠得住的，是把关键状态写入持久化层前加一层“原子提交”保障。
- 用
fopen(..., 'c')打开文件（而非'w'），避免清空原内容后断电导致全丢 - 写入时先写到临时文件（如
data.json.tmp），再用rename()原子替换——Linux下该操作在同分区是原子的 - 数据库操作务必用事务，且确认存储引擎支持崩溃恢复（如 MySQL 的
InnoDB，禁用MyISAM） - 避免依赖
__destruct()或对象析构——PHP可能在内存回收前就退出
UPS通信中断时PHP如何判断电源异常
不能等UPS发通知才反应——NUT（Network UPS Tools）服务挂掉或USB连接松动时，upsc 命令会直接失败或超时，PHP得主动探测。
- 用
exec('upsc myups@localhost battery.charge 2>/dev/null', $out, $code)获取电量，$code !== 0就代表通信异常，不是电量低 - 连续两次
upsc超时（建议间隔5秒）才触发降级逻辑，防止单次抖动误判 - 别用
shell_exec()——它不返回退出码，无法区分“没电了”和“UPS脱机了” - 如果用 SNMP 接 UPS，注意
snmpget在超时后默认返回空字符串，需显式检查empty($result) && $code !== 0
Web请求中止但PHP还在跑？关掉 output_buffering
用户浏览器关掉页面、网络断开，PHP 默认仍会继续执行完脚本，此时若正在写日志或更新状态，反而可能把半截数据刷进存储。
- 在入口脚本开头加
ignore_user_abort(false)（注意：不是true），让客户端断连后PHP尽快退出 - 确认
output_buffering = Off或设为0，否则fastcgi_finish_request()无法真正释放连接 -
connection_status() === CONNECTION_ABORTED只在 CLI 模式不可靠，Web SAPI 下更推荐监听pcntl_signal(SIGUSR1, ...)配合 NUT 的upssched发信号 - Apache 的
mod_proxy_fcgi有连接复用，需额外配置ProxySet timeout=10防止僵死连接拖住PHP进程
为什么不要在PHP里直接调用 shutdown -h now
断电保护不是靠“立刻关机”实现的——UPS供电时间有限，硬关机大概率卡在磁盘写入中途，比不断电更伤硬件。
-
shutdown -h now会同步刷所有脏页，SSD在掉电瞬间可能损坏FTL映射表；应改用sync && echo 3 > /proc/sys/vm/drop_caches提前清理缓存 - 真正该做的是：收到低电量信号后，用
systemctl stop php-fpm nginx mysql逐个优雅停止服务，留出3–5秒给它们完成最后写入 - PHP脚本内禁止用
exec('reboot')类命令——权限、SELinux、systemd 都可能拦截，且无法捕获失败原因 - UPS关机逻辑必须由系统级服务（如
nut-monitor）驱动，PHP只负责“记录状态+通知管理员”，别越权
硬件保护的关键不在PHP多快响应，而在它是否把控制权及时交还给系统层——很多故障，其实是PHP抢着干活，结果干了一半电没了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
