记录一次代码体检：290 行的 Streamlit（2026-05-28）
记录一次代码体检：290 行的 Streamlit（2026-05-28）自己写的东西，自己最不容易看出问题
那天没写新功能，做了两件更基础的事：给一套自己写的 Streamlit 做代码体检，再把另一个小项目的架构摊开看一遍。都是"回头看"的活，比往前冲更难受，但也更有用。
第一件：给效率分析系统做个体检被体检的是一个 290 行的 Streamlit 应用——效率分析管理系统。结构其实挺清楚，一共七个区块：
页面配置（7-13 行）
样式注入（15-35 行）—— 自定义 CSS，用 unsafe_allow_html
常量定义（37-52 行）—— 硬编码了 D:\work 路径和三个 Excel 文件路径，三组列名
Session State 初始化（54-69 行）—— 把三个表读进 session_state
工具函数（71-98 行）—— DataFrame 转 Excel bytes、校验列名后导入
主界面三个 Tab（106-282 行）—— 每个 Tab 都是"导入/导出/在线编辑"
页脚（284-28 ...
记录一次车间看板的搭建（2026-05-14）
记录一次车间看板的搭建（2026-05-14）需求很简单：让工时自己说话，别再靠人抄
车间里的工时数据是有的——机器一直在采，落在 MySQL 里。问题是没人看。数据躺在表里，要问产量就得有人去查、去汇总、去做表。信息在，但不在需要它的人眼前。
这块看板就是为了把这句话反过来：数据在哪儿产生，就在哪儿显示。
先看数据长什么样第一步永远是看表结构，而不是先想界面。
表是 work_load，在一台早期的 MySQL 上（100.64.0.2:3306，库叫 m3_ai_data）。字段不复杂：
字段
含义
START_TIME / END_TIME
一段工作的起止
WORKER_NUM
工位编号
WORKTIME
工时，单位秒
WORKLOAD
工作量，单位人·秒
AREA / MAIN_AREA
区域 / 主区域
两个细节后来证明很关键：工时是秒不是分钟，**工作量是"人·秒"**。也就是说，同是一小时，两个人干出来的是一个人的两倍——这一条决定了后面所有图表的口径。
还有一点，这几个字段都是 varc ...