为响应“人类百岁时代”数字化提速要求，6月中旬我们启动【企业大事记】栏目智能化改造，目标是实现“上传即生成、删除即消失”的全自动排序功能。这条路上先后踩了四个大坑，才最终跑通全流程。
dashiji1.html、dashiji2.html放入/fqtf/dashiji/子文件夹，导致主页扫描脚本找不到文件路径，按钮完全无法生成；二是硬编码路径写死，后续新增文章必须手动修改主页代码，完全违背“自动化”初衷；三是未考虑容错机制，误删文件后页面直接报错，差点导致整站瘫痪。V1.7版本一度被判定为“不可用”，改造计划被迫暂停。
6月下旬，我们从回收站找回此前测试的“哪吒版”雏形，以此为根基重构逻辑，确立了三条不可动摇的铁律：① 所有大事记文件必须直接放在网站根目录，与index.html平级，严禁嵌套子文件夹；② 扫描逻辑改为“从3开始自动递增”，永久保留前两个手动固定按钮，避免重复生成；③ 加入容错机制，文件不存在时自动跳过，不影响页面其他功能。V1.8基础版就此定型，为后续问题解决打下了地基。
即便V1.8基础版落地，我们仍花了3天时间啃下三个拦路虎：
1. 按钮不生成：排查发现是FTP上传后文件权限异常，调整为755权限后解决；同时反复验证“删除文件按钮自动消失”的容错逻辑，测试结果完全符合预期，这才确认基础扫描逻辑没问题。
2. 标题读不出来：初期上传的dashiji3.html未添加<title>标签，脚本只能抓取文件名显示。我们随即明确规范：所有大事记文件必须在头部添加<title>标签，内容为文章标题，这才解决了标题显示问题。
3. 字符乱码（BOM幽灵）的终极困境：这是最棘手的坑——Windows记事本默认的UTF-8 BOM编码会在文件头部添加隐藏字符，导致浏览器解析出“鍓嶅彴”“鎴戜滑”这类乱码。我们先后尝试了多种方案：昨晚先用Notepad++执行“转为UTF-8无BOM编码”操作，上传后网页乱码依旧；今早又重复尝试了两次，结果完全相同，彻底宣告本地编辑器编码方案的失败。最终我们放弃自主生成文件的方案，决定将所有大事记的HTML代码生成工作全部交由元宝完成，从源头规避本地编码干扰。
今天下午我们用宝塔面板内置文件管理器进行了最终压力测试，所有文件均由元宝生成后直接上传：
1. 上传测试：上传本文件后，前台【企业大事记】栏目秒级生成“大事记4”按钮，排版、标题完全正常，彻底解决了乱码问题。
2. 删除测试（能下）：在宝塔面板中删除该文件后，网站内容需手动刷新后按钮才会消失，这属于浏览器缓存的正常现象，不影响核心功能的完整性。
3. 重新上传测试：再次上传完善版文件，同样需手动刷新页面，新标题的按钮才会完全更新显示。
至此，“上传即生成、删除即消失”的全生命周期自动化管理功能已全部完成闭环，编码问题彻底根治。