app_debug = false 需同时清理缓存、确保 runtime 目录可写、检查 .env 优先级及入口文件环境变量设置，否则仍会降级为伪调试模式。
为什么 app_debug = false 不能只改配置文件就生效
ThinkPHP 在生产环境开启调试模式会触发大量日志写入、异常堆栈收集和模板编译检查，哪怕 app_debug 设为 false，如果缓存未清或配置被运行时覆盖，实际仍走调试逻辑。
- 必须同时确认
runtime/cache/和runtime/log/目录权限可写，否则框架会降级回“伪 debug 模式”——不报错但不缓存路由、不合并配置 -
.env文件中的APP_DEBUG=false优先级高于config/app.php，但若使用php think optimize:config预编译过配置，该命令会忽略.env，得加--force参数重生成 - 某些云环境（如阿里云函数计算）会把
$_ENV清空，此时必须在入口文件public/index.php顶部手动加putenv('APP_DEBUG=false');
路由缓存失效的三个典型场景
ThinkPHP 的 route:cache 命令生成的 runtime/route.php 是性能关键，但它极易因路径、命名空间或闭包写法被绕过。
- 使用
Route::get('/user/:id', 'controller@method')写法没问题，但若写成Route::get('/user/:id', [\app\controller\User::class, 'view'])，则无法被静态分析，缓存会跳过该路由 - 控制器类名含大小写混用（如
UserControllervsuserController），在 Linux 下因文件系统区分大小写，会导致路由匹配失败且不报错，只返回 404 - 在
route/route.php中直接写闭包（function() { ... }）将彻底禁用路由缓存——框架无法序列化闭包，每次请求都重新解析
db.query 和 Db::query 的执行开销差异在哪
两者都能执行原生 SQL，但底层调用链和连接复用机制完全不同，直接影响并发下的数据库连接数和响应延迟。
-
Db::query()走的是完整查询流程：获取连接 → 设置前缀 → 解析参数 → 执行 → 关闭语句 → 归还连接；而$db->query()（$db是Db实例）跳过前缀替换和部分安全检查，快约 12%～18% - 高频调用时，
Db::query()更容易触发连接池耗尽，尤其当database.connection_pool.max_active设为默认的 20，而你每秒发起 30 次查询时，会排队等待 - 如果 SQL 含变量拼接（非参数绑定），
Db::query()会自动转义，$db->query()不做任何处理——这里不是“更安全”，而是“更危险”，别为了省几毫秒自己拼字符串
模板引擎关闭 strip_tags 自动过滤后要注意什么
ThinkPHP 默认对 {\$var} 输出做 htmlspecialchars，但很多人误以为关掉 template.strip_tags 就能输出 HTML，其实它只控制是否移除标签，不控制是否转义。
-
template.strip_tags = true会把{\$content}中的<p>hello</p>变成纯文本hello；设为false并不会让 HTML 渲染，只是保留标签字符，仍需配合{\$content|raw}才真正输出 - 一旦用
|raw，所有用户输入内容必须提前白名单过滤（比如用htmlpurifier），ThinkPHP 自带的think-helper里没有轻量 HTML 过滤器 - 模板中混用
{\$var}和{\$var|raw}时，若template.cache开启，两种输出方式会被编译成不同缓存文件，但缓存 key 不包含过滤器信息，可能导致一个缓存命中另一个渲染逻辑
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
