起因：我只是想把做好的页面放到网上
做过独立产品或者小工具的人大概都遇到过这种情况：页面早就做好了，就是一个 index.html 加几个 CSS、JS 文件，双击就能在浏览器里打开。可一旦要把它"放到网上"，事情突然变复杂了——要不要接 GitHub？要不要配置 CI/CD？要不要用 Docker 打包？要不要挂到 Cloudflare？
对于一个真正的大项目，这些工具都有价值。但如果我只是想做十个、二十个小工具页面，每个都轻量到几百 KB，为了"上线"这件小事去搭一整套流水线，明显是杀鸡用牛刀。
核心想法：产品就是一个文件夹，发布就是上传
这个平台的想法其实很朴素：
一个产品，就是一个装着
index.html、CSS、JS、图片的文件夹。把它打包成一个 ZIP，填一个短名字（比如pdf-editor），上传，几秒钟后就能在你的域名/pdf-editor/打开。
没有构建过程，没有远程仓库，没有第三方云服务。平台只做四件事：校验 ZIP、解压、记录版本、把网址指过去。产品里用什么框架、写什么风格,平台完全不关心——甚至每个产品之间也互不干扰，A 产品的一次更新绝不会波及 B 产品，因为它们各自是完全独立的文件夹，没有共享任何代码或资源。
两个容易被忽略但很关键的细节
发布要么成功要么没发生，不能卡在中间。 每次发布,系统不是覆盖旧文件,而是先把新版本准备好放在别处，最后一步"啪"地把网址指向新版本——这个切换是一个原子操作，用户永远只会看到"旧版本"或"新版本"，不会看到一半新一半旧的尴尬状态。出了问题也能一键回滚到任意历史版本，因为每次上传的版本都被完整保留，从不覆盖。
只有平台自己的程序能写文件，网页服务器（Nginx）只能读。 这样即使上传接口出了 bug，最坏情况也只是发布失败，而不会有人通过一个上传漏洞篡改已经上线的页面。
文章也是同一套逻辑
平台后来又加了"文章"功能——写产品思路、更新日志之类的内容。做法跟产品一模一样：写 Markdown，通过后台接口发出去，系统转成一个静态的 HTML 页面，跟产品页面并排显示在首页上。本质上还是那句话：内容是内容，平台只负责把它稳稳地摆到网上。
最近的一次小改进
一开始要发布内容，得打开管理后台的网页,一步步点。但如果习惯了在本地写文章、写产品，更自然的方式是:内容都攒在自己电脑上一个文件夹里，写完直接用一条命令同步到线上,不用再手动点后台。
于是加了一个小工具，本地约定好目录结构（文章放 Markdown，产品放构建好的文件夹），跑一条命令，它会自动登录后台、创建或更新内容、然后发布——本质上和手动点后台做的事完全一样，只是省掉了鼠标点击的步骤。这篇文章本身，就是用这个方法发布出来的。
小结
这套平台没有什么高深的技术，它的价值就是"够用就好"：把发布这件事压缩成"打包、上传、给个名字"三步，把复杂度都藏在背后，让人可以把精力放在真正重要的事情上——做好产品本身。