2026 年，我的独立开发技术栈

每年都有新框架。我现在选技术栈，先看两年后还愿不愿意维护。

这套是我 2026 年实际在用的，覆盖博客、投研仓库和微信小程序。它不一定适合别人，但对我够用。

层	选择	用在哪
站点	Astro / VitePress	博客、笔记，静态输出
语言	TypeScript	CLI、前端、脚本
前端	React	只在需要复杂交互的研究站
运行时	Node.js	CLI、云函数、构建脚本
数据	PostgreSQL / JSON + Markdown	要事务时上 PG；研究事实源用文件
部署	Cloudflare Pages / Workers、Vercel、Sealos Cloud、Docker	静态优先，常驻服务才上容器
工作流	AI coding + 小步提交	先给上下文，再读 diff

站点：Astro 和 VitePress

博客用 Astro，笔记站用 VitePress。内容都是 Markdown，构建完是静态文件，不需要服务器和数据库。

搜索索引在构建期生成，客户端只做过滤；RSS、sitemap、canonical 也都在构建时确定。没有运行时、没有数据库连接，流量上来也不会打挂服务。部署和迁移就是搬一堆文件。

语言：TypeScript

从 CLI 到前端，我尽量只用 TypeScript。

hp-research 的 CLI、导出器、评分逻辑都是 TS；博客和站点也用 TS。同一个数据契约，在脚本、接口和页面里是同一套字段名，来回切换的成本低。

我不追求复杂的类型技巧，能把输入输出写清楚就够。

前端：React 只在研究站

研究站需要图表、筛选、日期切换和复杂的表格，所以用 React + Vite 做 SPA。博客只是展示内容，Astro 的静态输出就够了。

内容站不需要客户端路由和状态管理，也就没必要引入一整套 SPA 运行时。

数据：先定事实源

数据库不是默认选项。先看这份数据需不需要事务、并发写和复杂查询。

• 研究系统：本地 JSON / Markdown 是事实源，方便 diff、回滚和人工审阅
• 需要事务和查询的业务：PostgreSQL
• 微信小程序：直接用云开发的数据库，不额外养一套后端

同一个项目里也可以混用。先定哪份数据说了算，再决定它存在哪。

部署

博客和文档站放 Cloudflare Pages；轻量接口用 Workers；需要常驻进程或本地依赖的服务，才用 Docker。

我没有上 Kubernetes，目前没有需要集群的场景，现有的 Pages、Workers 和 Docker 够用。静态站构建完只有 dist/，用 Wrangler 发布，也可以让 Pages 接 GitHub 自动构建。

免费额度

独立开发早期，能免费跑起来很重要。我现在这套里，免费或低成本的部分大概这些：

工具	用在哪	注意
Cloudflare Pages / Workers / D1	博客、研究站、授权申请站	个人量级够用；D1 适合轻量关系数据
Resend	授权邮件、通知邮件	免费额度按量；发信域要验 SPF/DKIM
Sealos Cloud	Trade Signal 的 PostgreSQL、feed 服务	有免费额度；按量资源，注意上限
Vercel	Next.js 站点	Hobby 免费；商用条款看清
Bark	iOS 推送	免费；token 当密钥保管
GitHub Actions / Pages	CI、静态站	公开仓库免费；私有仓库有额度

这些免费额度适合先把事情跑起来；等量真的上来，再为稳定性付费。

AI coding 不在表里

AI 不属于技术栈的某一层，但它影响每一层怎么写。

我现在的流程是：每个仓库一份 AGENTS.md，第一段写清楚“这个项目是什么、不是什么”；开新会话先让它读；改动小步提交；最后自己读 diff。AI 能写完大部分代码，但其中有一部分只是“看起来对”，验证成本仍然在自己这边。

2026 年写代码本身变便宜了，判断和验证反而更花时间。

我刻意不用的东西

• 微服务：个人项目没有那么多边界要拆
• Kubernetes：没有集群需求，就不引入集群复杂度
• 过早的 monorepo：两个包之前，先别搭工作区

这些方案本身没问题，只是不适合我现在的项目规模。

最后

这套技术栈没有什么新鲜东西。Astro、TypeScript、React、Node.js、PostgreSQL、Cloudflare，都是常见选择。

它们文档全，遇到问题能搜到答案。省下来的时间可以放在产品上。