访问日志仅记录http元信息，需在caddyfile中显式配置{ log }全局块才输出；php错误日志由php.ini的error_log和log_errors控制；stderr是所有关键日志的第一现场，业务日志须由应用层单独输出。
访问日志（access.log）只记录 HTTP 请求元信息
它由 Caddy 层生成，内容固定：状态码、请求路径、客户端 IP、响应耗时、User-Agent 等，不包含 PHP 执行细节。比如 404 是路由没匹配到，500 是 PHP 脚本抛出未捕获异常——但你不会看到哪一行 PHP 代码出错。
默认不输出，必须在 Caddyfile 中显式写 { log } 全局块，否则连 200 请求都看不到。
-
log块只控制 HTTP 层日志，和 PHP 错误无关 - 输出目标默认是
stderr（终端），不是文件；要落盘得加output file /var/log/frankenphp/access.log - 格式默认是纯文本，要 JSON 得手动配
format json，且仅限这一层
运行日志（PHP 错误日志）来自 PHP 自身机制
它记录 Fatal error、Warning、Notice 等运行时问题，由 PHP 解释器触发，走的是 php.ini 里的 error_log 和 log_errors = On 配置。
FrankenPHP 不接管也不修改这套逻辑——它只是“运行 PHP”，所以 error_log("msg") 输出到哪、parse error 写进哪个文件，全看 php.ini 实际生效路径。
- 用
frankenphp php-cli -i | grep error_log查当前生效的error_log路径 - 单文件交付时，客户机器上的
php.ini可能完全不可控，别依赖它 - 启动失败时的
panic: runtime error或failed to load extension也出现在 stderr，不属于error_log文件
stderr 是所有日志的第一现场
无论访问日志是否配置、PHP 错误是否写入文件，frankenphp run 启动后所有关键信息——包括 Caddy 初始化、PHP worker 启动、解析错误、panic 堆栈——都直接打到进程的 stderr。
这意味着：
- 服务起不来？第一反应不是翻
/var/log，而是看终端最后一行输出 - Docker 环境下，
docker logs -f看的就是这个stderr流 - systemd 管理时，
journalctl -u frankenphp -n 50 -f抓的也是它
业务日志不能混进这两类里
订单创建、用户登录、支付回调这类业务行为，既不在 access.log（它没上下文），也不该塞进 error_log（它专管错误，且权限/轮转难控）。
正确做法是应用层自己写：
- 用
Monolog+StreamHandler写入固定路径，如/var/log/myapp/app.log - 或统一打到 stdout，用
error_log(json_encode($data), 0)输出单行 JSON，交给日志采集器解析 - 绝对避免裸调
error_log("xxx", 3, "/tmp/app.log")—— 并发写乱序、无锁、不轮转、路径权限常失效
log 块就万事大吉，结果 PHP Fatal error 没进任何文件；或者把业务日志全扔进 error_log()，导致线上磁盘一夜爆满。日志链路必须分层设计，不能指望一个配置兜底。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
