phpEnv中Nginx的access_log必须用绝对路径，如C:/phpEnv/logs/myapp_access.log；log_format须定义在http块顶层；日志轮转需手动或用Windows计划任务+PowerShell；敏感信息必须在log_format中脱敏，禁用$request_body等高危变量。
phpEnv里Nginx的access_log路径不能直接写相对路径
phpEnv启动的Nginx进程工作目录不固定（常为安装目录或桌面路径），access_log logs/access.log 这类相对路径极易写入失败，日志文件可能出现在意想不到的位置，甚至静默丢弃。必须用绝对路径。
常见错误现象：修改配置后 access_log 指令生效但日志文件始终为空；nginx -t 检测通过，但 tail -f 看不到任何输出；Windows资源管理器里找不到 logs/ 文件夹。
- 确认 phpEnv 的 Nginx 配置文件真实路径：通常在
C:\phpEnv\nginx\conf\nginx.conf或你自定义的站点配置目录下（如C:\phpEnv\sites\myapp\nginx.conf） - 把
access_log logs/access.log main;改成类似access_log C:/phpEnv/logs/myapp_access.log main;（注意 Windows 下用正斜杠或双反斜杠） - 确保目标目录
C:/phpEnv/logs/存在且 phpEnv 启动的 nginx 进程有写权限（一般以当前用户身份运行，无需管理员权限） - 避免使用带空格或中文的路径，比如
C:\My Logs\或C:\phpEnv\日志\—— nginx 在 Windows 下对这类路径解析不稳定
log_format 必须定义在 http 块顶层，不能放在 server 或 location 里
phpEnv 的 Nginx 默认配置中，http 块已包含 log_format main，但如果你要加自定义格式（比如记录 $request_time 或 $http_x_user_info），必须把它写在 http { ... } 大括号最外层，否则会报错 unknown log format "custom"。
典型错误：把 log_format custom '...'; 直接塞进某个 server 块里，重启时 nginx -t 提示语法错误，但 phpEnv GUI 界面可能不显示具体报错，只提示“服务启动失败”。
立即学习“PHP免费学习笔记（深入）”；
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
- 打开
C:\phpEnv\nginx\conf\nginx.conf，找到http {开头的位置 - 在
include mime.types;后、任意server块前插入：log_format custom '$remote_addr - [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_response_time'; - 然后在对应
server块中使用：access_log C:/phpEnv/logs/custom.log custom; - 不要在同一个配置中重复定义同名
log_format，nginx 不会覆盖，而是报错
phpEnv 的 Nginx 不自带 logrotate，得手动轮转或用 Windows 工具
Linux 上习惯用 logrotate 管理日志切割，但 phpEnv 是 Windows 环境，Nginx 自身不提供自动归档功能。放任 access.log 持续追加，几个月后就可能达到 GB 级，拖慢分析、占满磁盘。
错误做法：以为加了 gzip=1 flush=10s 就能自动压缩归档 —— 这些参数只控制内存缓冲和写盘时机，不涉及文件切分。
- 最简方案：用 Windows 计划任务 + PowerShell 脚本，每天凌晨把
myapp_access.log重命名为myapp_access.log.20260424，再 touch 一个新空文件 - 更稳妥方式：用第三方工具如 logrotate-win，配置类似 Linux 的规则（
daily、rotate 30、compress） - 注意权限：脚本或工具需以与 phpEnv 相同的用户身份运行，否则无法 rename 正被 nginx 占用的日志文件（Windows 下文件锁严格）
- 测试轮转是否成功：改系统时间跳到第二天，看旧日志是否归档、新日志是否从零开始写入
敏感信息脱敏必须在 log_format 里做，不能靠后期过滤
phpEnv 常用于本地开发调试，容易忽略日志安全。比如 PHP 应用把 token 或手机号塞进 X-User-ID 头，又被 $http_x_user_id 直接记入日志 —— 这些明文数据一旦导出或误传，就是泄露风险。
很多人想“先全量记录，再用 grep 或脚本脱敏”，但问题在于：日志文件本身已含敏感内容，哪怕删掉某行，磁盘未覆写的扇区仍可能恢复原始数据。
- 禁用高危变量：
$request_body（含 POST 数据）、$args（含完整 query string）、$http_authorization、$http_cookie—— 不要出现在任何log_format中 - 若必须记录用户标识，优先用前端可控字段，如
$http_x_forwarded_for（需确认可信代理链）或应用层生成的匿名 ID（由 PHP 注入X-Trace-ID） - Windows 下无
sed实时过滤，所以“写入即脱敏”是唯一可靠路径；例如用正则替换$http_x_user_info中的手机号："$(echo $http_x_user_info | sed 's/\b1[3-9][0-9]{9}\b/****-****-****/g')"—— 但 nginx 不支持这种 shell 表达式，只能靠应用层预处理 - 真正可行的做法：PHP 在响应头中只传脱敏后的值，比如
header('X-User-Safe: u_abc123')，然后log_format里只取$http_x_user_safe
实际配置中最容易被忽略的是 Windows 文件锁机制 —— nginx 在写日志时会独占打开文件，外部程序无法直接 truncate 或 move，必须先发 USR1 信号通知 nginx 重新打开日志文件（但 Windows 不支持 USR1）。所以所有轮转动作，本质都是“停止 nginx → 切日志 → 启动 nginx”，而 phpEnv 的 GUI 启停逻辑未必兼容这个流程。动手前，先在命令行用 C:\phpEnv\nginx\nginx.exe -s stop && ren C:\phpEnv\logs\access.log access.log.20260424 && C:\phpEnv\nginx\nginx.exe 手动跑通一遍。
