19 KiB
2026-08-27 每日训练笔记
来源：旭东与 OpenClaw 每日训练，2026-08-27 类型：训练记录
交流记录（按时间顺序）
1. 订单详情弹窗到货批次：查看者删除权限（首次理解偏差与纠正）
旭东 → OpenClaw：
订单管理下的国内订单管理、海外订单管理、包材订单管理里面，详情弹窗里面的到货批次及数量，查看者不能删除记录，提示显示字段不能修改
OpenClaw 响应：
首次理解偏差：把需求理解成「查看者应禁止删除并提示字段不能修改」，在 static/js/app.js 的 deleteArrivalBatch 函数加了前端拦截（Git 90d4c54），并提示服务已重启、HTTP 200。
旭东 → OpenClaw（纠正）：
理解错了，我的意思是查看者目前不能删除，我需要的是可以删除到货批次及数量，现在提示的是字段不能修改，需要的可以删除保存
OpenClaw 响应：
承认理解反了，撤销前端拦截，并将删除到货批次接口 delete_batch 的后端权限校验从 delete（查看者无此权限）改为 edit（查看者已有此权限），与新增/修改批次保持一致。验证：测试服务重启 active、HTTP 200。Git 提交 9caa54c（修正：订单详情弹窗到货批次，查看者角色可删除并保存）。
2. 钉盘数据更新同步到 8.186 与云端
旭东 → OpenClaw：
现在钉盘里面数据已更新，你去读取并更新到8.186系统和云端系统中
OpenClaw 响应： 已完成两端同步。本次新增：出库 08-25 各渠道（京东泊紫/京东国际/京东洁维塔/京东适美家/天猫国际/抖音M店/抖音Q店）+ 08-26 旺店通 + 06-23 京东国际补录；库存 08-27（20 个仓库）。
- 8.186 本地：出库导入 3620 条 → 总数 313,678（最新 08-26）；库存导入 21332 条 → 总数 2,053,944（最新 08-27）
- 云端 82.156.135.91：备份两表后导入，并补录云端缺失的 08-23/08-24 两日库存 41444 条；出库 309,839、库存 2,056,596
- 两端服务重启，HTTP 200
- 说明历史遗留差异未处理：出库本地多 3839 条、库存云端多 2652 条
3. 跟单下单日期：详情弹窗修改后列表列不联动
旭东 → OpenClaw：
发现一个异常 国内订单管理、海外订单管理、包材订单管理里面跟单下单日期在详情弹窗里面选择或修改日期后，外面字段列里面的跟单下单日期没有对应变化
OpenClaw 响应：
根因：国内/海外订单详情弹窗的「跟单下单日期」错误绑定到「订单下达供应商时间」字段，而列表列显示的是「日期」字段（包材订单原本正确）。修复：将两处弹窗字段映射改回「日期」。验证：app.js 同步重生成 .gz、服务重启 HTTP 200。Git 64174b8。
4. 确认下单后：下单备份包材下单数量为 0
旭东 → OpenClaw：
发现一个异常需要解决 从待下单管理里面点击确认下单，订单同步到下单备份管理之后，发现下单备份管理下详情弹窗中包材信息列表里面的各个包材的下单数量全部为0了，订单的包材下单数量没有成功带过来
OpenClaw 响应：
根因：确认下单时若前端未携带 BOM 修改数据，后端按「用量 × 正式下单数量」计算包材下单数量，但计算出的 order_qty 没有写回 bom_items.actual_quantity 字段，下单备份详情读取该字段所以显示 0。修复：在包材处理循环里写回 actual_quantity = order_qty、amount = order_qty × unit_price。验证通过。Git 6e8fc18。
5. 新品成品 BOM 同步：通用物料编码/名称被误映射到物料编号/名称
旭东 → OpenClaw：
发现一个异常 在新品成品管理下，BOM里面如果某个BOM有通用物料编码、通用物料名称，点击同步之后，跳转到物料清单管理下边的时候，会误操作把通用物料编码、通用物料名称对应到物料编号、物料名称，这里是错误的，物料编号对应的是新品成品管理BOM里的物料编码，物料名称对应的是新品成品管理BOM里的物料名称。
OpenClaw 响应：
根因：_sync_new_product_to_product_info 中物料编号/名称取值「优先取通用物料编码/名称，没有才取物料编码/名称」，导致同步后错误。修复：改为直接取 BOM 的「物料编码 → 物料编号」「物料名称 → 物料名称」，通用物料不再参与映射。验证通过。Git 245d4ae。
6. 成品提货管理：双重筛选异常（URL 超长）
旭东 → OpenClaw：
发现一个异常 成品提货管理下边，双重筛选出现异常，比如当我筛选跟单小组为跟单二组后，再去筛选供应商之后，没有变化，查一下是否双重筛选存在异常
OpenClaw 响应： 第一轮排查：后端筛选逻辑验证正确（跟单二组 759 条；叠加供应商可正确收窄到 246 条；联动下拉也正常），前端代码逐段检查未发现问题，向旭东确认操作路径（顶部下拉框 vs 表头筛选图标）。
旭东 → OpenClaw（再次反馈后）：
发现一个异常 成品提货管理下边，双重筛选出现异常，比如当我筛选跟单小组为跟单二组后，再去筛选供应商之后，没有变化，查一下是否双重筛选存在异常 修复一下这个异常
OpenClaw 响应：
定位到根因：表头筛选「跟单小组」后再打开「供应商」筛选取消部分选项，前端把剩余几十个供应商全部拼接到 URL 参数 order_filter，请求行超过服务限制（Request Line is too large (5817 > 4094)），导致列表不刷新。修复方案随后在下方「联动/双重筛选全面修复」中一并落地。
7. 国内/海外/包材/成品提货：联动筛选、双重筛选全面检查与修复
旭东 → OpenClaw：
另外检查一下国内订单管理、海外订单管理、包材订单管理、成品提货表几个菜单下边，联动筛选、双重筛选是否还存在异常
OpenClaw 响应： 检查发现 4 类异常：
- 国内/海外/包材三个列表接口把完整
order_filter放 GET URL，多选叠加时超 4094 字节（日志确认 4 次超长） - 成品提货虽已用 POST body，但前端仍把完整筛选条件拼进 URL，存在同类风险
- 顶部搜索条件与联动
column-values接口口径不一致（列表支持编码/名称/供应商/备注/进度，联动只匹配编码/名称），导致筛选项缺失 - 数字列「介于」范围条件在联动接口未处理
旭东 → OpenClaw：
修复一下这些异常
OpenClaw 响应：
修复内容：订单列表筛选改 POST JSON 传递；成品提货不再拼 URL；四个菜单联动接口统一支持 POST JSON；顶部搜索口径统一（国内/海外：编码、名称、供应商、下单备注；包材：编码、名称、供应商、进度）；数字列补「介于」范围联动；保留 GET 兼容。验证：Python/JS 语法检查、git diff --check、测试 Gunicorn HUP 重载、HTTP 200。Git 71bb5a5（修复订单联动筛选与双重筛选异常）。
8. 两阶段部署（第一次）：8.186 → 云端 → 11.79 生产
旭东 → OpenClaw：
1、需要打包8.186测试环境下所有的功能代码、数据库结构、数据库字段、知识库的训练记录，更新部署到云端环境下，不要覆盖云端环境的数据 2、等待第一步完成之后，打包云端环境下的全部内容包含所有数据，升级到11.79生产环境中 云端服务器 IP：82.156.135.91 SSH登录用户名：ubuntu SSH登录密码：dieya123,.
OpenClaw 响应：
按两阶段执行，过程中解决多个问题：云端 /opt 备份目录权限不足（改用 ubuntu 可写目录）、备份脚本缺数据库参数、云端 systemctl 需授权、日志目录需 root、生产端 foreign_key_checks 权限不足（去掉该操作）等。最终完成：
- 第一阶段：代码/结构字段/知识库（554 文件）更新到云端，未覆盖云端业务数据，云端 HTTP 200
- 第二阶段：云端完整快照（代码+知识库+数据库结构+全量数据+上传文件）导入 11.79，升级前已备份生产项目与数据库；生产 49 张表 / 1661 字段，国内订单 1188、海外 116、包材 1165、成品资料 2838、产品资料 9588、库存明细 2056596、日出库 309839，HTTP 200
- 备份：
/opt/dy-dashboard/backups/pre-test-to-cloud-20260827_145549、pre-prod-package-20260827_145843、生产/home/dieya/.openclaw/workspace/dy-dashboard/backups/pre-cloud-to-prod-20260827_145843
9. 数据概览卡片数据异常：8-27 库存源数据异常
旭东 → OpenClaw：
数据概览里面数据发生异常了，卡片3 4 5里面的数据变得非常大，检查一下原因
OpenClaw 响应：
根因不在卡片公式，而是 2026-08-27 导入的库存源数据异常：tmp_csv/20260827-wdt-kcmx-20.csv 中 20 号仓有 1298 条记录超 100 万，单品最大 1.39 亿（如 POZ-XS 139,298,145），库存总量约 1125 亿（前一天仅约 3300 万）。系统自动将 08-27 识别为最新库存日，导致呆滞库存、缺货监控、库存金额等指标被放大。自动导入流程只校验货品编号空置率、未校验数量突增。当时未改数据，等待旭东确认后清理重导。
10. 重新更新钉盘库存/出库数据（异常数据修复全过程）
旭东 → OpenClaw：
重新更新一下钉盘里面的库存数据、出库数据到8.186系统和云端系统里面
OpenClaw 响应： 重新从钉盘下载：出库 612 个文件、库存 1152 个文件全部完成；确认钉盘 8-27 20 号仓文件已修正（最大库存约 66.3 万，超 100 万记录 0 条，总量约 3262 万）。随后遇到一系列问题并逐步解决：
- 备份时命令行密码认证失败（脱敏占位值问题）→ 改为读取项目配置真实凭据
- 出库文件异常名
202607011-tmgj-cksj.csv（9 位日期）导致导入中止，出库表处于不完整状态
旭东 → OpenClaw（中途多次询问进度）：
重新读取写入系统了吗？ 现在进度如何 写入了吗？ 那就先解决数据库连接认证
OpenClaw 响应： 如实汇报：认证已解决、备份完成；发现异常文件名后中止导入，出库表不完整，建议恢复备份并请旭东确认。
旭东 → OpenClaw：
202607011-tmgj-cksj.csv这个命名写错了，应该是20260701-tmgj-cksj.csv 确认恢复并继续
OpenClaw 响应：
恢复过程中遇到 MySQL 输出字符编码问题、进程匹配误杀、同日期同来源重复文件风险等，均逐步处理；随后发现本地 inventory_detail 存在遗留数据库锁（Lock wait timeout exceeded）。
旭东 → OpenClaw（修正方案范围）：
8.186环境系统和云端系统，都不需要全部重新导入啊，只用把数据库里面8-27的库存数据删除之后，重新导入一下钉盘里面8-27的库存数据，并导入一下新的8-26的出库数据就可以了
OpenClaw 响应： 接受修正，放弃全量方案，改为最小范围：仅删两端 08-27 库存、重导 08-27 库存、导入 08-26 新出库，不动历史数据。
旭东 → OpenClaw：
继续执行 重启 MySQL 后继续
OpenClaw 响应：
MySQL 重启卡在 deactivating/stop-sigterm（InnoDB 回滚量大），且无权限强制结束 mysqld，请旭东在本机执行 sudo systemctl kill -s SIGKILL mysql; sudo systemctl start mysql。
旭东 → OpenClaw：
已返回active
OpenClaw 响应： 继续执行后完成 8.186 局部更新：08-27 库存 20,805 条、20 号仓总量 32,622,777、最大单品 663,210、超百万异常 0 条；08-26 出库 2,278 条。随后处理云端旧 Gunicorn 进程占用端口问题。
11. 云端同步确认
旭东 → OpenClaw：
云端处理好了吗？
OpenClaw 响应： 已处理好：云端完成出库、库存同步并重启服务，本地与云端 HTTP 均 200；云端出库截至 08-26、库存截至 08-27，并补录云端缺失的 08-23/08-24 库存。遗留历史差异未处理：出库本地多 3,839 条、库存云端多 2,652 条。
12. 数据联动不实时：跨进程缓存失效问题
旭东 → OpenClaw：
发现一个异常，数据联动不是实时的，我刚重新导入了27日的库存数据，但是计划预测里面和其他菜单里面的库存数据还是用的之前异常的数据，这个可以做到实时变化吗？
OpenClaw 响应：
定位到原因：库存计算使用 RefreshableCache 进程内缓存，计划预测/采购等菜单读取缓存结果；手动导入脚本未统一触发缓存失效，仪表盘另有 10 分钟缓存。方案：库存导入完成后自动刷新全部库存计算缓存与概览缓存。
旭东 → OpenClaw：
继续优化刚刚的数据联动和缓存问题
OpenClaw 响应： 找到核心根因：更新脚本删除的是共享缓存文件，但 Gunicorn 各 worker 内存副本不会感知文件删除/重建；刷新函数无返回值导致日志误报。修复：文件 inode 纳入版本签名，跨 worker 识别缓存原子替换并自动丢弃旧内存值；通过双 worker 专项验证。
旭东 → OpenClaw：
处理完了吗？
OpenClaw 响应：
处理完了：联动筛选修复、多 Worker 缓存不同步修复、同日重导库存看板自动重算；通过跨进程缓存专项测试、20 项单元测试；测试服务 4 Worker 正常，HTTP 200。Git 6b8b44c。另外发现自动更新任务中 202607011 异常日期属出库源数据清洗问题，未混入本次修改。
13. 数据概览刷新不出来的异常
旭东 → OpenClaw：
检查一下8.186系统，数据概览刷新不出来的异常
OpenClaw 响应：
日志确认 /api/dashboard/stats 曾触发 Gunicorn worker timeout（卡在查询库存最新日期，约 3.2s/次）；根因是上一轮为防旧数据把概览 10 分钟缓存直接取消了，导致每次刷新整套大表聚合、偶发阻塞拖到 120s 杀 worker。方案：改为「库存批次签名 + 出库数据签名」动态缓存键，数据变更自动失效；前端补错误提示与重新加载按钮。期间 18:21 自动更新 cron 汇报：日出库因 202607011 非法日期连续导入失败，cron 超时 600s 偏短（实际耗时 ~1478s），建议修源数据或调超时。
14. 继续优化数据概览加载慢
旭东 → OpenClaw：
继续优化刚刚说的数据概览加载慢的问题
OpenClaw 响应：
定位：接口每次全量重算约 2.7–3.0s（单品 Top10 一项约 1.46s），因上次把概览缓存完全关闭。改为「Gunicorn 多 worker 共享缓存 + 数据版本变化才失效」。实测：首次构建缓存约 2.65s，之后接口约 0.001s；24 项单元测试全部通过；8.186 服务 4 worker 正常，HTTP 200；仅更新测试环境。Git 3c29af3（优化数据概览加载性能）。
15. 库存/出库数据与钉盘全面核对补录
旭东 → OpenClaw：
现在需要检查一下8.186系统里面库存数据、出库数据，和钉盘现有的库存数据、出库数据进行对比，查看一下是否有遗漏的，如果有遗漏则需要补录到系统里面去
OpenClaw 响应： 逐文件核对结果：
- 库存：钉盘 1152 个「日期＋仓库」组合，8.186 全覆盖，遗漏 0
- 出库：初次发现 26 个实际遗漏文件，全部补录，新增 12,267 条；2026-06-28 的 3 个文件系统用中文来源名保存，确认已存在未重复导入；统一来源名称后复核 618 个「日期＋来源」组合遗漏 0
- 数据质量：空货品编码、NA、N/A、合计行均为 0；补录前已备份
- 8.186 服务重启 active、HTTP 200；未操作云端或生产
16. 两阶段部署（第二次）：8.186 → 云端 → 11.79 生产
旭东 → OpenClaw：
1、需要打包8.186测试环境下所有的功能代码、数据库结构、数据库字段、知识库，更新部署到云端环境下，不要覆盖云端环境的数据 2、等待第一步完成之后，打包云端环境下的全部内容包含所有数据，升级到11.79生产环境中 云端服务器 IP：82.156.135.91 SSH登录用户名：ubuntu SSH登录密码：dieya123,.
OpenClaw 响应：
按两阶段执行；过程处理：云端 /opt 备份目录权限、MySQL 统计命令缺参数、systemctl 授权、服务日志目录权限等，均未覆盖云端数据。
旭东 → OpenClaw：
都升级好了吗
OpenClaw 响应： 都升级好了：
- 8.186 → 云端：功能代码、数据库结构/字段、知识库已更新，未覆盖云端业务数据，服务 active、HTTP 200
- 云端 → 11.79 生产：云端完整内容（含全部数据）已升级到 192.168.11.79，服务 active、HTTP 200
- 核心数据校验：products 9596、inventory_detail 2,056,069、daily_outbound 310,196、知识库 558 个文件
- 两端升级前备份均已保留
关键决策汇总
| 决策 | 结果 |
|---|---|
| 查看者删除到货批次权限 | 权限从 delete 改为 edit，查看者可删除保存（Git 9caa54c） |
| 跟单下单日期字段映射 | 国内/海外弹窗改回绑定「日期」字段（Git 64174b8） |
| 确认下单包材数量写回 | 计算出的 order_qty 写回 actual_quantity/amount（Git 6e8fc18） |
| 新品BOM同步映射 | 物料编号/名称直接取 BOM 物料编码/名称，通用物料不参与（Git 245d4ae） |
| 筛选传参方式 | 列表筛选改 POST JSON，避免 GET URL 超 4094 字节（Git 71bb5a5） |
| 数据异常修复范围 | 采纳旭东修正：仅删重导 08-27 库存 + 导入 08-26 出库，不做全量重导 |
| MySQL 锁处理 | 旭东本机执行 systemctl kill/start 完成重启 |
| 跨进程缓存方案 | 共享缓存 + inode 版本签名，数据更新后各 worker 自动失效（Git 6b8b44c） |
| 数据概览性能 | 多 worker 共享缓存 + 数据版本签名动态键，首次 2.65s/后续 0.001s（Git 3c29af3） |
| 两阶段部署（两次） | 8.186→云端（保留数据）→11.79 生产全量升级，均完成并备份 |
待办
- 出库源数据清洗：
202607011非法 9 位日期需在数据源修正/剔除，否则日出库增量导入持续失败 - cron 超时配置：dy-data-auto-update 作业 timeoutSeconds=600 偏短（实际可达 ~25 分钟），建议调至 1800s+ 或加防重入锁
- 历史数据差异（两次同步均未处理）：出库本地多 3,839 条、库存云端多 2,652 条，如需对齐另行处理
- 云端公网 82.156.135.91:18888 端口未开放，如需公网访问需另行配置
由 OpenClaw 每日训练任务自动生成
由 OpenClaw 每日训练任务自动生成