第一个域名临期四天才惊觉源码尽失，只留十九份手工拷贝的数字化身

threadkeeper.io 是我首个注册的域名，登记日期为 2025 年 8 月。当时正值社区学院的 AI 夏令营结束后，电脑里留存着若干 ccc-ai-pdf-project 类型的 Python 初学者项目。经过六周的持续开发，我完成了域名、博客、CLI 及宣言的部署——全程通过 Spaceship 的浏览器编辑器实现，既未搭建过 Git 仓库，也未执行过 git commit 命令，甚至连本地版本控制都未设置。

页面的顶部使用青色字体标注了 "Don't commit without context." 的警示语。然而，讽刺的是，我从未执行过一次提交操作。

续费提醒送达后，我选择放弃续费。出于怀旧心态，我登录了域名后台进行查看，大约花费了五分钟时间。试图下载代码以作纪念时，却意外发现：唯一的代码副本正运行在即将关机的服务器上。

在面临数据丢失的紧急情况下，我立即采取了抢救措施。我下载了八个页面以及所有静态资源：包括首页、博客、三篇文章、Dr. Kahlo 页面，以及一个基于 AWS 黑客松项目开发的 Ariadne Clew 应用。这些文件总计 19 个。sitemap.xml 文件声称仅包含四个页面，但这显然与 2025 年的我当时的认知不符。

目前，这些文件已迁移至 GitHub Pages，并为每个文件附加了 SHA-256 哈希值，以验证其内容的完整性未被篡改：

earlgreyhot1701d.github.io/threadkeeper-archive

这一刻，我终究还是实现了版本控制，尽管来得有些迟。

在重新审视代码时，我注意到第一个问题出现在 Ariadne Clew 项目中，该项目的七个 JavaScript 模块混合了两种命名规范：

• snake_case + _js.js 后缀：例如 api_js.js、dom_js.js、main_js.js
• camelCase 无后缀：例如 utils.js、theme.js、exportMarkdown.js、dragDrop.js

在同一个文件夹内，七个文件却采用了不同的命名风格。

当聚焦于 dom_js.js 文件时，我意识到其命名存在重复扩展名的问题："dom, js, dot js"。这一命名习惯的根源我非常清楚：在聊天窗口中复制代码块时标注为 dom_js，保存文件时顺手添加了 .js 后缀，在实现基本功能后便忽略了规范的命名。文件名实际上成了记录来源的收据，表明"这些文件是从对话框中复制来的，而非在项目中独立开发"。

main_js.js 文件的起始部分包含六个 import 语句，其中第三个为：

import { getElement, getValue, ... } from './dom.js';

然而，服务器上的实际文件名为 dom_js.js。

由于 ES 模块需要先解析完整的依赖图才能执行，缺少 dom.js 文件导致整个模块图无法正常工作——没有部分执行，也没有降级机制，即使其他五个 import 语句能够正常解析，也无法挽救全局。

页面上所有的交互功能均绑定在 main_js.js 文件中：表单提交、内容复制、导出功能、主题切换、拖拽操作、初始 UI 状态等，全部因缺少依赖而崩溃。

左侧页面呈现为完美的静态展示，而右侧控制台则显示一行红色错误信息：

Failed to load resource: the server responded with a status of 404 (dom.js)

这一错误信息是在域名到期前的四天左右，我在本地浏览器中观察到的现场。当时的页面虽然静态内容完整，但没有任何交互功能。

回顾整个过程，我意识到一系列低级错误导致了问题的发生：未建立 Git 仓库、未进行本地开发、缺乏构建流程、未启用类型检查，甚至文件名的大小写也未保持统一。尽管如此，这也构成了我唯一的开发路径——只有将代码部署到生产环境，并让其充分暴露在运行中，下一次才会深刻认识到版本控制的重要性。

存档中还保留了完整的控制台日志和网络请求瀑布图，有兴趣的读者可以自行查阅。

这一事件强调了在开发过程中实施版本控制的重要性，尤其是在处理静态网站和前端项目时。当开发者在生产环境中部署代码后，若发现依赖缺失或其他问题，应立即采取补救措施，并确保未来的项目从最初阶段就纳入版本管理。这一经验教训适用于任何开发团队或个人，特别是那些初次接触 Web 开发的初学者。