一个人开发网站，到底需要哪些技术？

看 10015.io 的技术栈会有点意外：Next.js 加 styled-components，没有 UI 组件库。作者 Fatih Telis 是前端开发者，他不可能不知道组件库怎么用，他是算过账的——50 多个工具、Chrome 和 Firefox 扩展，至今 MRR 约 300 美元，任何一个需要长期维护的额外依赖都是负担。

10015.io 首页放着 Chrome 和 Firefox 两枚扩展入口——工具集的分发不只靠网页。

一个人做站需要的技术，清单比大多数人想象的短。可以按"不做会死"来排。

第一项：让 HTML 在服务端就有内容

这条不是性能优化，是能不能被搜到的前提。

一个工具站的价值来自页面矩阵：每个工具一个 URL、一个页面、一个独立搜索入口。如果这些页面是前端路由渲染出来的空壳，搜索引擎抓到的是同一份空 HTML，矩阵就等于不存在——你有 50 个工具，在搜索那边只算 1 个页面。

所以第一项必须会的是：让框架在服务端（或构建时）把页面骨架生成好。用前端 JavaScript 处理交互完全没问题，问题只在于首屏的 HTML 里得有真实内容。验证方式很土但有效：curl 一下页面，看返回的 HTML 里有没有那句话；或者关掉浏览器的 JS 再打开。两种都过，才算这一项达标。

Omni Calculator 是这条逻辑走到极致的样子。它把计算器抽象成配置、页面由模板生成，2026 年 6 月的估算访问量约 1429 万、支持 30 多种语言。它不可能手写上千万个页面，靠的就是"配置 + 模板 + 预渲染"这套结构。

第二项：把计算留在浏览器里

10015.io 的原则值得背下来：几乎所有工具在客户端运行，极少请求服务端。

判定条件前面说过：输入能不能进内存、处理能不能在几秒内结束、结果要不要落盘。三个都是否定的就放浏览器。这直接决定成本曲线——工具从 1 个涨到 50 个，服务器开销几乎不动。

要补的技术因此很明确：文件格式转换、编解码、压缩、重计算这类活，用 WebAssembly 跑现有 C/C++ 库，性能接近原生，而且没有上传下载的带宽成本。ffmpeg 编译成 wasm 之后，视频转码这种重活也能留在客户端。

这一项的收益是双份的：服务器账单小了，而且你可以对用户承诺"文件不上传"。代价是 wasm 文件要按需加载，别塞进首屏包里——这是客户端计算方案唯一要额外操心的地方，做法就是动态 import，等用户真的要用那个工具时再拉。

第三项：存数据，但别急着上数据库服务

MVP 阶段很多东西根本不需要落库——输入进来、算完、返回，中间没有要留下的东西。

需要持久化时，SQLite 是默认答案：一个文件，没有独立进程，备份就是复制文件，单机读性能对小型站绰绰有余。必须换成独立数据库服务的信号只有两个：出现多机写入，或者并发写把单文件写锁顶住了。

Cakedesk 走的更远。Max Schmitt 一个人做的桌面端发票应用，Electron 加 React 加 Node.js，数据全在用户本机，一次性 €69 无订阅，2025 年卖出 239 份新授权。它连服务端都不存在，运维成本是零，代价是分发变成了打包 Electron 应用。

部署上只需要两样：容器和反向代理

一个人不需要 k8s，不需要 CI/CD 平台，不需要服务网格。需要的只有两个东西。

一个是把应用和环境打包成镜像。用 Docker 写一份 Dockerfile，本地跑通的那个环境原样搬上服务器，避免"在我机器上是好的"。配合 compose 文件，应用、数据库、定时任务一次拉起。

另一个是把外部请求转进来。Nginx 做的是三件具体的事：监听 443 终结 TLS、把请求反代到容器里那个端口、直接 serve 静态文件。工具站里大量内容是纯静态的，交给 nginx 直出比穿过应用层快得多，这一层配置对 Omni Calculator 那种规模尤其重要——它的广告负责人 Alexander Utz 说过，页面速度对他们没有商量余地，整个增长依赖 SEO，Core Web Vitals 直接进排名。

还得会一件：看懂自己机器现在的状态

不是要搭监控平台，是要能在出问题时三分钟内知道原因。四件具体的事：

看日志。docker logs 加 tail 能解决大部分"页面白屏"的排查，错误栈通常在最后几十行里。

看内存和负载。free -m 和 uptime，判断是内存不够还是 CPU 顶住了，两者对应的处理方式完全不同。

看慢查询。数据库那层开个慢日志阈值，超过一定时间的语句记下来。多数性能问题最后都落在缺索引上。

看磁盘。工具站最常出的事不是 CPU 爆了，是磁盘被上传的文件或者日志悄悄填满。

这四件事花不了半小时学会，但能省掉大量"不知道为什么挂了"的时间，而且它们都不需要装任何平台。

明确不需要会的部分

可以放心跳过：微前端、GraphQL、消息队列、分布式缓存、多区域部署、自建监控栈。这些是解决"多人协作"和"百万级并发"的工具，一个人、几千日活的项目里，它们的净收益是负的。

也可以推迟：单元测试体系、TypeScript 全量改造、设计系统。这些在方向验证之前做，属于提前支付成本。

真正值得提前的只有两项——服务端渲染和客户端计算。它们决定了页面能不能被搜到、以及成本随不随用户量涨，这两件事后期改动的代价都极高。你现在的栈里，这两项处在什么位置？