页面异常时，详细错误可能帮助维护者，但不适合无范围地展示给所有访客。成都企业维护WordPress网站时，可以把对用户的可理解提示与内部技术证据分别设计。隐藏错误不等于修复故障，开启日志也不代表已经定位原因。
先记录现象与影响范围
故障证据卡，不填写凭据
完整问题入口：
时间与环境：
最近已知变更：
可重复步骤及受控测试标识：
访客实际反馈：
内部记录位置及允许读取者：
当前判断与仍缺证据：WordPress官方介绍WP_DEBUG、WP_DEBUG_LOG和WP_DEBUG_DISPLAY等选项。它们分别涉及调试及输出安排，具体组合和主机行为需要由有权限人员核对。本文不直接给生产设置值，避免读者把调试演示当作长期运行方案。
访客需要下一步，维护者需要证据
| 对象 | 应获得的内容 | 不应混同 |
|---|---|---|
| 公开访客 | 清楚状态与可用路径 | 内部堆栈、路径或秘密 |
| 维护人员 | 受控错误与执行条件 | 凭一张截图猜全部原因 |
| 业务接收者 | 受影响任务与待处理项 | 直接读取所有技术记录 |
| 项目负责人 | 恢复范围及未完成事项 | 只收到已修好三个字 |
- 先保存授权范围内的现象与最近变更。
- 在合适环境核对调试与记录安排。
- 使用专用测试定位具体操作。
- 修复后复测原问题及受影响路径。
排查结束也要处理记录安排
日志可能含不宜公开的内容，读取、留存和清理需要明确责任。不要把完整记录贴进公开文章或群聊，也不靠文件名难猜作为保护。对外只提供解释问题所需且经过审核的信息；维护交接保留必要技术证据与未解决项。
1原现象同条件下核对问题是否消失。
2业务检查必要保存与读取路径。
3范围记录哪些对象已验证，哪些仍观察。
4交接确认后续监测与记录处理责任。
关闭错误显示能解决白屏吗？
不能把显示安排当成故障修复，需要继续检查真实响应与执行。
日志越详细越好吗？
以定位需要和受控处理为准，不无目的收集或公开信息。