生产环境必须关闭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 里并推到远程仓库，等于公开招标黑客来爆破你的数据库。更糟的是，本地和线上共用同一份配置，一测就崩。
生成周报：读取本机 Git 仓库最近一周的提交记录，按项目分类提炼总结，生成标准周报格式，通过微信推送并返回给用户。触发词：周报、weekly report、git总结、提交记录总结、工作周报。
立即学习“PHP免费学习笔记（深入）”；
- 用环境变量接管：PHP 7.1+ 直接用
getenv('DB_PASSWORD')，或通过$_SERVER读取（Nginx/Apache/FPM 均支持注入） - FPM 示例：
env[DB_HOST] = "127.0.0.1"写进www.conf；Nginx 示例：fastcgi_param DB_HOST "10.0.1.5"; - 绝对不要在代码库中留
.env文件——把它加进.gitignore，上线时由运维单独部署
文件权限设成 777 图省事，结果被上传木马
为了「让 Laravel 能写日志」或「让 WordPress 能装插件」，把整个 storage/ 或 wp-content/ 设成 777，等于给攻击者开了个 shell 入口。PHP 进程用户（如 www-data）只需写权限，不需要执行权限。
- 标准做法：目录
755，文件644；可写目录（如storage、runtime）属主设为 Web 用户，权限755（不是777） - 用
chown -R www-data:www-data storage/+find storage/ -type d -exec chmod 755 {} \;+find storage/ -type f -exec chmod 644 {} \; - 特别注意
public/.htaccess或nginx.conf是否禁止访问storage/目录下的.php文件——否则上传一句话木马就能直接执行
权限、错误显示、入口路由、字节码缓存、配置隔离——这五处一旦漏查，轻则功能异常，重则数据泄露。尤其 opcache.validate_timestamps 和 display_errors，看似小开关，实际决定线上系统是「稳住」还是「裸奔」。
