PHP无内置DEBUG/RELEASE编译区分，需通过环境变量（如APP_ENV）、常量（如DEBUG）或运行时上下文在运行时识别环境，并据此配置error_reporting、display_errors等行为。
PHP 本身没有内置的 DEBUG 常量，所谓 “开启 DEBUG 模式” 实际上是各类框架或项目约定俗成的行为，不同环境下的写法、生效位置和副作用差异极大——直接全局定义 define('DEBUG', true) 几乎不会起作用，反而可能掩盖真实问题。
ThinkPHP 5/6 中 APP_DEBUG 的实际生效位置
TP5 和 TP6 对 APP_DEBUG 的处理逻辑完全不同，混用会导致调试开关失效：
- TP5：必须在入口文件（如
index.php）顶部用define('APP_DEBUG', true)定义，且必须在加载框架前执行；配置文件里的'app_debug' => true是无效的替代写法，仅部分旧文档误传 - TP6：
APP_DEBUG只从.env文件读取，写成APP_DEBUG=true即可；入口文件中再用define()覆盖无效，因为框架启动时已由Env类提前解析并固化 - TP6 若需运行时动态切换（如后台开关），必须同时调用
App::debug(true)和Env::set('APP_DEBUG', 'true')，缺一不可——只改其中一个，日志、SQL 记录、模板重编译等行为会不一致
WordPress 的 WP_DEBUG 不只是显示错误
WP_DEBUG 开启后默认只在页面输出错误，但真正影响线上稳定性的其实是它的配套常量：
-
WP_DEBUG_LOG设为true后，所有错误会追加写入wp-content/debug.log；若该文件不可写，错误将静默丢失，而不是报错提示 -
WP_DEBUG_DISPLAY控制是否把错误直接输出到 HTML，生产环境务必设为false，否则敏感路径、数据库凭证可能随错误堆栈泄露 - 单独开
WP_DEBUG而不开WP_DEBUG_LOG，等于只做“实时喊话”，没留下任何可追溯记录，上线前排查历史问题时基本无用
原生 PHP 的 error_reporting 和 display_errors 更底层但更关键
框架的 DEBUG 模式最终都依赖 PHP 底层的错误控制机制，绕过它等于自废武功：
立即学习“PHP免费学习笔记（深入）”；
-
display_errors决定错误是否输出到页面，error_reporting决定哪些错误级别被触发；两者必须配合使用，例如ini_set('display_errors', '1'); error_reporting(E_ALL & ~E_NOTICE); - 在 CLI 环境下（如命令行跑脚本），
display_errors默认为Off，即使开了APP_DEBUG也看不到报错，得靠error_log或重定向 stderr - 某些共享主机禁用
ini_set()，此时只能修改php.ini或.user.ini，且需确认allow_url_include和disable_functions未屏蔽相关函数
最易被忽略的一点：框架级 DEBUG 模式（如 APP_DEBUG）通常会强制关闭缓存（模板、字段、路由），但如果你在中间件或钩子中手动调用了 clearstatcache() 或反复 include 同一文件，性能下降可能比预期剧烈得多，而错误日志里不会体现这点。
