生产环境必须关闭display_errors并启用log_errors，配置正确入口路由，开启OPcache且设validate_timestamps=0，用环境变量隔离数据库配置，严格控制文件权限为755/644。
PHP线上部署时 display_errors 还开着？赶紧关掉
生产环境开启 display_errors 是最常见也最危险的疏忽——错误堆栈直接暴露在用户页面上，可能泄露路径、数据库结构甚至敏感配置。PHP 默认开发环境常设为 On，但上线前必须确认被禁用。
- 检查
php.ini：确保display_errors = Off，同时log_errors = On（错误会写入error_log文件） - 若用 FPM，别只改 CLI 的
php.ini，要确认www.conf中的php_admin_flag[display_errors] = off生效 - 在代码里用
ini_set('display_errors', '0')是无效的——该指令是PHP_INI_SYSTEM级别，运行时无法修改
Web 服务器没配好 index.php 入口，404 到底是路由还是配置问题？
Nginx 或 Apache 没正确设置前端控制器（Front Controller），会导致除根路径外所有 URL 返回 404，新手常误以为是 Laravel/ThinkPHP 路由没写对，其实根本没进 PHP。
- Nginx：必须有
try_files $uri $uri/ /index.php?$query_string;，且location ~ \.php$块中包含fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;（避免$document_root在 symlink 下出错） - Apache：确认
.htaccess可读且AllowOverride All已启用；或直接在虚拟主机配置里写RewriteRule ^(.*)$ index.php [L] - 测试方法：临时在
index.php顶部加die('hit');，访问任意非根路径（如/test），如果没输出，说明请求根本没落到index.php
opcache.enable 没开，或开了却没配 opcache.validate_timestamps
没启用 OPcache 是性能隐形杀手；而启用了却没调好验证策略，则会导致「改了代码不生效」——新手常因此反复清浏览器缓存、重启 PHP-FPM，最后发现是 OPcache 在缓存旧字节码。
- 确认
opcache.enable=1（CLI 模式默认关闭，不影响 Web，但要检查 FPM 的php.ini） - 线上务必设
opcache.validate_timestamps=0（禁用文件时间戳检查），否则每次请求都 Stat 所有 PHP 文件，IO 开销大且易因 NFS/挂载延迟导致异常 - 配合部署流程：更新代码后执行
opcache_reset()或curl -X GET http://your.site/opcache-reset.php（该脚本需含权限校验）
数据库配置硬编码在代码里，还提交到了 Git？
把 DB_HOST、DB_PASSWORD 写死在 config/database.php 里并推到远程仓库，等于公开招标黑客来爆破你的数据库。更糟的是，本地和线上共用同一份配置，一测就崩。
