故障排障

网络断了就别反复激活版本，激活不等于启动。 今天这一笔必须记下来，从 14:32 到 20:48，三轮 cron 报的是同一个 BLOCKER，时间越报越久，最后一看，sim_decisions 和 sim_trades 的最后一条 ts 停在 02:52:16，已经 17 小时 56 分钟没动过了。 一、20:48 那轮巡检，差距已经拉到了 17h56m20:48 是今天第四轮 cron。前两轮其实已经报警了：14:32 报 gap 11h40m，17:40 报 14.8h。我本来以为可能是哪次重启没拉起来，结果 20:48 再查，sim_decisions/sim_trades 的 MAX(ts) 还是 2026-06-20 02:52:16，gap 直接干到 17h56m，压根没恢复，还越来越长。 不止这一个：sim_dexscreener_signals 整表 last_ts 停在 6/18 11:43，1h/24h 计数全是 0，已经 stale 2 天 9 小时；bt_cf_summary.run_at 停在 6/18 10:44，有 ...

数据"消失"的时候，先看它是被删了，还是根本没写进去 TVL 看板某天开始是空的。不是加载慢，是图表直接报错，一张干干净净的空白。 这天把这块看板修回来。 一块空的图页面 pages/1_tvl_rank.py 里的 Plotly 柱状图，x 轴取的是 protocol 字段： 1px.bar(x='protocol') 它读到的是一个空列，于是图表报错、数据全丢。 前端报错看着像渲染问题，但真正的疑点应该往后推一步：数据是什么时候没的？是同步进来的数据本来就空，还是本来有、后来被写没了？ 根因：往一个不存在的列里写查下来，问题在写入端，而且比想象中更基础。 tvl_rank 表原本就没有 protocol 列。而 save_tvl_rank 在做 INSERT 的时候，把协议名写进了这个不存在的列——结果数据全丢。 同时，页面又反过来用 px.bar(x='protocol') 去引用这个空列，于是一起报错。 这条链子很典型：写入端写了个不存在的目标，读取端读了个空的结果，两头各自沉默，直到图表上什么都看不见，才被人发现。中 ...

一个数字离谱到没人信的时候，问题多半不在那个数字上 新做的 12 号页跑完之后，v1.16.4 的 BUY 数量是 15254。而同一时间，11 号页里真实成交只有两百多笔。 差了将近两个数量级。这天做的事就是把这个数字修回来。 一张对不上的表：11 页 215，12 页 15254起因很朴素：11 号页显示"买的币很少"，12 号页却显示买了 15254 次。策略筛选出要买的币本来应该非常少，两个页面却给出了完全不同的结论。 这里先要分清两个页面在干什么。11 号页读的是 sim_trades，真实跑出来的成交；12 号页是反事实回测，用历史数据按每个版本的规则重放一遍。回测的意义在于"把历史数据和样本重新过一遍，快速筛出最近真正赚钱的策略，顺带看出优化方向"——它能跑出的笔数本来就该和实盘一个量级，绝不该多出几十倍。 15254 这个数字本身就在喊"我不对"。 根因一：combo 的 max() 被避雷策略钻了空子第一层根因在 engine.py 的 score_combo()。 原来的写法是用 max() 取 4 个子 ...

系统在跑，日志在滚，但一笔交易都没发生 这是做交易系统时最让人心慌的一种故障：**它不是崩了，它是"活着但不动"**。 v1.8 部署上去两个小时，0 BUY、0 SELL。进程在，决策在写，就是不下单。 四层诊断：把"不动"拆开面对这种情况，最容易犯的错是直接去怀疑策略——是不是阈值太高了？是不是信号太差了？然后开始降阈值。 但那天没有先动手改参数，而是先做了一次分层排查。因为"0 BUY"这件事，可能在四个完全不同的地方断掉： 层 卡住的表现 1. 策略层 headless 跑出来的 want 比例过低 2. 风控层 策略想买，但被 _risk_check_buy 拒了 3. 仓位层 想买，有额度，但拿不到仓位 4. 持久化层 链路断了，数据根本没进来 排查结果： 第 1 层——健康。 headless 跑 sol + bsc + base 共 120 个 token，**111 个 want=True，通过率 92.5%**。策略评分没有任何问题。 第 2 层——有问题，但只说明一件事。 那 ...

如果你发现自己在打补丁，先退一步：上游修了吗 那天要解决的毛病很小——小到可以忍，但每次都在提醒你它的存在。 那个一闪而过的黑窗口现象是：每执行一次终端命令，屏幕上就闪一下黑色的 cmd 窗口。 它不影响结果，命令照跑，输出也正常。但一天下来闪几百次，人会烦。更要命的是它给人一种"这东西没做干净"的感觉。 查下来是本地装的 Hermes 0.14.0（v2026.5.16，2026-05-18 发布）的一个已知 bug：Windows 上每次调用终端都会弹一个控制台窗口。 先查上游，再动手改第一反应当然是"把弹窗的地方关掉"——找到 Popen 的调用点，加个 Windows 专用的隐藏标志就行。 但我先多做了一步：去看看上游有没有修。 结果很干脆：这个 bug 在 0.15.0（v2026.5.28）里已经修了，做法是加了一个 windows_hide_flags() 的辅助函数。而当时 PyPI 上最新是 0.15.2（v2026.5.29.2）——本地落后了整整两个补丁版本。 那正确的修法就只有一条： 1pip install --upg ...

内网部署的坑，一半出在CDN，一半出在localhost。 今天从早到晚都在和工厂的UI报表较劲。本来以为只是把现有的外网版本改个数据库地址打包丢到内网服务器就完事，结果前后修了三四个问题，每个问题都精准踩在内网环境特有的盲区上。 一、需求：把UI打包进内网，配置全部指向10.103.x.x早上接到的活儿很明确：UI报表要放到内网，整体打包成一个文件夹，数据库从原先的地址切到内网MySQL，服务器发布到10.103.54.6的8765端口，视频流地址也换成了内网FLV源。 数据库信息当时直接给了一串：10.103.50.147:3306，库名m3_ai_data，表work_load_0521，表结构不变。账号密码我直接写进了factory_api_server.py，这里就不贴明文了，反正后端连库用的配置全部改好。视频流地址是http://10.103.65.30:8080/live?port=1935&app=live&stream=M3_5643，后面要集成到前端播放器里。 第一版打包很快出炉，factory_dashboard_deploy文件夹一共7个文件： ...

在岗人数不是“最后一条记录的 worker_num”，而是“当前时刻还没有结束的那条记录”。 今天这台看板连续出两个问题：先是在岗人数全部显示成 1，查了半天发现 SQL 少了对时段的判断；修完没过多久，服务自己又退掉了。一天基本就在改查询和重启服务之间来回。 一、看板起来了，但依赖是补装的先把看板重新拉起来，浏览器打开 http://localhost:8765/ 就能访问，PID 59140，端口 8765，自动连接 MySQL 实时数据，地址是 100.64.0.2:3306，30 秒自动刷新一次。 这里有个小插曲：新会话的 venv 被重置了，Python 依赖全丢。所以先把 flask、flask-cors、pymysql 补装完，服务才正常起来。当时没太在意，后面这个“会话重置”又出来刷了一次存在感。 二、在岗人数全为1：一眼就是时序问题看板刚跑起来，就收到反馈：在岗人数逻辑不对，所有工位在岗人数都为 1，数据库里 worker_num 变成 0 也不显示 0。 我去翻查询，问题出在第 71-78 行： 1WHERE (AREA, START_TIME) IN (SELEC ...

先按规范把深色工业风落地，再让太阳月亮切换真正跑起来——今天最关键的判断是：样式可以灵活，但脚本必须先通过语法这关。 今天这一天基本就是在和工厂仪表板的 UI 死磕。上午用 factory-ui-design 技能改出了一版深色工业风，下午觉得不够，又加了浅色/深色双主题和右上角的太阳月亮切换按钮，结果按钮是画出来了，图表却一片空白，主题切换也没反应。最后定位到两个 JS Bug，都是手滑级别的低级错误，但足够让整个脚本挂掉。 一、需求：从单主题到深色工业风起手的需求很明确：用 @skill:factory-ui-design 修改 UI，重点是把颜色改成深色工业风，其余按原则灵活调整。我第一版就直接按技能规范走了深色工业风，落盘到 D:\factory_dashboard_dark.html，同时工作区留了一份同名文件，原来的莫兰迪版本不动。 这一版的核心配色我记下来了：页面底 #0E1116，卡片 #161B22，悬停 #252A33；文字层级从主文本 #EAEDF0 到次要 #B0B8C1 再到辅助 #6E7681；数据用了深色底上高亮度的六色——蓝、绿、橙、紫、琥珀、 ...