Python
在一个多 worker 的 Python 服务里，日志按天落盘本来是件很普通的事，但真正跑进 Docker 和多进程环境之后，事情往往没有想象中那么简单。我们这次遇到的，就是一个非常典型、也非常容易被忽视的问题：日志文件日期彻底混乱了。 最离谱的时候，目录里会看到一个名字像这样的文件： app.log.2026-04-18 但打开之后，里面却混进了 2026-04-23 的日志。 这种现象第一眼看上去很玄学，实际上原因并不玄学。核心就是一句话： 多 worker 进程同时写同一个轮转日志文件，天然就容易出事。 这篇文章把这个问题的成因、误区，以及我们当前先落地的临时方案整理一下。也提前说明：这不是最终版日志架构，只是先把现在线上最痛的跨天串文件问题止住。 背景 项目运行在 Docker 里，服务启动方式是： uvicorn src.main:app --host 0.0.0.0
AI
最近在给这套商品图提示词服务接入新的 OpenAI-compatible 供应商时，我们踩了一个很典型、也很容易误判的坑： * 同样是 /chat/completions * 同样是 OpenAI 兼容请求格式 * 旧供应商 qwen3-vl-plus 跑得很正常 * 新供应商 gemini-3-flash-preview 却频繁只返回半句话 最开始看现象，直觉很容易往这几个方向怀疑： * 这个供应商的 OpenAI 兼容实现不完整 * 多模态图片传递格式不对 * 响应解析逻辑没兼容到位 * 模型本身不稳定 但最后复盘下来，真正的主因比想象中直接很多：我们显式传了 max_tokens，而这个第三方 OpenAI-compatible 供应商上的 gemini-3-flash-preview 组合，很可能把图片理解和推理消耗也算进了输出预算里，导致最终文本阶段只剩下一小截。 这篇文章就把整个问题、排查过程和最终处理方法完整记录一下。 背景 我们的服务很简单： 1. 前端提交商品标题、图片 URL、模型配置 2. 后端调用 Op
Python
背景 一个平时很稳定的服务，在 2026-04-02 这天突然出现“连续失败”。 最让人难受的不是失败本身，而是失败信息太少：日志里只有一串「第 1 次请求失败」，没有异常类型、没有耗时、没有栈。 这种时候人的直觉会把怀疑撒向四面八方：逻辑是不是坏了、参数是不是不对、上游是不是抽风、网络是不是波动……但没有证据，一切都只是猜。 1. 先把故障“照亮”：只补日志，不动行为 线上系统已经跑了很久，第一原则是：先让问题可见，但不要一上来就改主逻辑。 我加的日志只做两件事： * 把“这次请求到底发生了什么”讲清楚 * 保持所有行为不变（重试次数、超时、请求参数、返回解析都不动） 具体补充项包括： * 请求开始时的关键信息（目标地址、超时、参数摘要、prompt 长度） * 当前是第几次重试、总重试次数 * 每次请求耗时
陕公网安备61011302002223号