phpEnv 的 error_log 不支持自动按天切割，因其仅接受静态路径且不解析日期占位符；必须依赖 logrotate（推荐）或应用层自定义日志逻辑实现轮转。
phpEnv 本身不提供日志切割功能，必须靠外部工具（logrotate）或 PHP 应用层逻辑实现 —— 直接改 phpEnv 配置文件无效。
为什么 phpEnv 的 error_log 设置不能自动按天切割
phpEnv 是一套 PHP 环境部署脚本（常用于 Windows + WSL 或轻量 Linux），它只负责安装、启停和配置 PHP-FPM/Apache，但 error_log 指令在 php.ini 中仅指定「写入哪个文件」，不包含轮转逻辑。PHP 官方至今未内置按时间/大小自动切分错误日志的能力。
常见误操作：在 phpEnv 的 php.ini 里写 error_log = /www/wwwlogs/php_error_%Y-%m-%d.log —— 这不会生效，PHP 不解析日期占位符，最终会创建字面名为 php_error_%Y-%m-%d.log 的文件，且所有错误都往里追加。
- PHP 的
error_log是纯路径字符串，不支持变量或格式化 - 即使配合
date_default_timezone_set()，也无法影响error_log的文件名生成 - 想靠修改 phpEnv 启动脚本注入动态路径，会因进程长期运行而失效（日期不变）
logrotate 是唯一可靠方案（适用于 phpEnv 所有部署场景）
无论 phpEnv 跑在 Ubuntu、CentOS 还是 WSL，只要系统装了 logrotate（默认已装），就能接管 PHP 错误日志切割。关键是路径要对、权限要准、copytruncate 要有。
立即学习“PHP免费学习笔记（深入）”；
假设你的 phpEnv 把 PHP 错误日志设为 /www/wwwlogs/php_error.log（这是宝塔系常见路径，也是 phpEnv 常用路径），则配置文件应这样写：
# /etc/logrotate.d/phpenv-error
/www/wwwlogs/php_error.log {
daily
missingok
rotate 30
compress
delaycompress
copytruncate
create 644 www www
notifempty
}-
create 644 www www：新建日志文件时设属主为www（对应宝塔/lnmp 的 Web 进程用户），不是root；若你用的是www-data，请同步改成www-data -
copytruncate必须存在 —— 否则 PHP-FPM 进程持续持有文件句柄，rename失败，旧日志继续增长 - 路径必须和
php.ini中error_log的值完全一致（包括符号链接目标），否则 logrotate 找不到文件 - 配置保存后无需重启任何服务，logrotate 每天通过 systemd timer 或 cron 自动触发
验证 logrotate 是否真正在工作
别等第二天看有没有 .1 文件。现在就执行两步确认：
第一步，检查配置语法和路径匹配：
sudo logrotate -d /etc/logrotate.d/phpenv-error
重点看输出中是否出现 considering log file /www/wwwlogs/php_error.log，以及有没有 skipping 或 error: 提示。
第二步，强制触发一次轮转并观察结果：
sudo logrotate -f /etc/logrotate.d/phpenv-error
- 执行后，原
/www/wwwlogs/php_error.log应变为空文件（copytruncate效果） - 同时出现
/www/wwwlogs/php_error.log.1，且ls -l显示属主是www、权限-rw-r--r-- - 立刻
tail -f /www/wwwlogs/php_error.log，手动触发一个 PHP 错误（比如访问一个不存在的.php文件），确认新日志有内容写入
如果 phpEnv 运行在无 root 权限的共享主机上
你无法写 /etc/logrotate.d/，也不能跑 sudo，这时只能退回到应用层方案，但要注意限制：
- 不能依赖
error_log全局设置 —— 改不了底层行为 - 只能在 PHP 脚本开头用
ini_set('error_log', ...)动态设路径，再配合每日定时任务（crontab）移动+清空 - 例如每天 00:00 执行：
/usr/bin/php /path/to/cut_error_log.php，脚本内判断日期是否变化，是则重命名旧文件、touch 新文件 - 风险点：高并发下多个请求可能同时写入同一文件，且
touch后权限可能不对（需chown www:www） - 更稳妥的做法是彻底弃用
error_log，改用自定义set_error_handler()+file_put_contents()写入带日期的文件，自己控制打开/关闭
这种方案绕开了 phpEnv 的限制，但也把日志可靠性交给了你自己 —— 文件锁、权限、磁盘满处理，都得一行行补全。
