为什么先看日志，而不是先改代码

个人博客上线后，最常见的故障不是复杂架构问题，而是一个表单提交失败、一次图片上传报错、一个后台页面突然 500。很多人第一反应是直接改代码，但如果没有先看日志，很容易把真正的问题盖住：可能是数据库文件没有写权限，可能是 Nginx 限制了上传大小，也可能只是某个环境变量没有在 systemd 里配置。

排查的第一步不是猜，而是把请求链路拆开。浏览器访问页面，先到 Nginx，再转发给 Gunicorn，最后进入 Flask 应用。任何一层都可能记录不同的线索。Nginx 日志告诉你请求有没有到达服务器、状态码是什么、响应体大概多大；Gunicorn 或 Flask 日志告诉你 Python 代码在哪里抛错；数据库日志或异常栈能指出字段缺失、锁等待或权限问题。

先确认是哪一类错误

如果用户说“页面打不开”，不要直接进入代码。先按三类问题分类。

第一类是入口不可达。表现通常是浏览器连接超时、502、503。优先检查 Nginx 是否运行、Gunicorn 是否监听本机端口、systemd 服务是否重启失败。

第二类是应用异常。表现通常是 500，Nginx 能收到请求，但 Flask 在处理时抛出了异常。这个时候重点看应用日志里的 traceback，尤其是最后三到五行。

第三类是业务结果不符合预期。比如提交文章后没有发布、评论不显示、搜索结果为空。这类问题不一定有异常栈，需要结合数据库状态和业务字段判断。

一个实用排查顺序

第一步，看健康检查。访问 /healthz，如果健康检查失败，说明问题还没有到业务页面层面，先查进程和依赖。

第二步，看 Nginx 错误日志。如果出现 upstream connection refused，通常是 Gunicorn 没起来或端口不一致。如果出现 client intended to send too large body，说明上传大小被 Nginx 拦住。

第三步，看应用服务日志。systemd 托管时可以用 journalctl -u 服务名 -n 100 --no-pager 查看最近错误。不要只看第一行，真正的错误原因通常在 traceback 最底部。

第四步，复现同一个请求。带着相同账号、相同表单、相同文件大小再试一次，确认问题可复现。不可复现的问题先记录现场，不急着大改。

慢请求怎么处理

慢请求不一定是代码慢，也可能是图片太大、数据库没有索引、外部接口等待太久。个人博客里最常见的是列表页查询过多、文章详情页做了额外统计、图片没有压缩、后台一次加载太多记录。

可以先从页面级别判断：只有首页慢，通常看文章列表和侧边栏聚合；只有文章详情慢，重点看 Markdown 渲染是否每次动态执行、相关文章查询是否过重；只有后台慢，重点看分页和统计。

总结

日志排查的核心是先定位层次，再定位代码。先问请求有没有到 Nginx，再问有没有到 Flask，最后才看业务逻辑。把路径、状态码、耗时和异常栈对齐后，大多数个人博客问题都能在十几分钟内缩小范围。