独立开发一年，我总结了5条「不废话」的技术原则

2026-05-16 17:46 · 4 次浏览 · 0 条评论 · 0 cool

1. 数据库设计：前期偷懒，后期加倍偿还

我第一个项目的表结构改了11版。不是业务变了，是一开始没想清查询路径。
现在我的原则：

每张表必须有  created_at  和  updated_at 。别问，问就是被排序需求坑过。
 
外键用逻辑关联，不用数据库外键约束。独立开发经常删库重构，物理外键是脚镣。
 
预留 JSONB 字段。业务字段变更是常态，PostgreSQL 的 JSONB 能救急，但别滥用——搜索频繁的字段必须正规化。
一个血泪教训：我曾把用户配置全塞 JSONB，后来要按配置筛选用户，全表扫描直接卡死。重构花了3天。

2. API 设计：先写文档，再写代码
独立开发没有前后端扯皮，但自己跟自己扯皮更可怕——今天写的接口，下周自己都不记得字段含义。
我的做法：

用 Swagger/OpenAPI 写接口定义

用 openapi-generator 生成前端 TS 类型

再开始写后端实现

好处：前后端类型自动同步，改接口时编译器直接报错，不用人肉对字段。

工具链：Stoplight Studio（写文档）→ openapi-typescript（生成类型）→ MSW（前端 mock 数据）。全程不手写类型定义。

3. 错误处理：不要  try-catch  了之
我见过太多代码：
js
try {
  await doSomething()
} catch (e) {
  console.log(e)  // 或者更糟：直接吞掉
}

独立开发没有 SRE 兜底，错误处理就是生命线。
我的错误分级：
表格
级别
处理
示例
用户错误
返回 400，带明确提示
参数缺失、格式不对
业务异常
返回 409/422，前端可预期
库存不足、重复提交
系统错误
500 + 告警通知
DB 连接失败、第三方 API 超时
未知错误
500 + 详细日志 + 立即修复
不应该出现的场景
关键：错误响应必须包含  error_code ，不要让用户靠解析字符串判断错误类型。

4. 部署：Git push 即上线，但要有回滚
我用 GitHub Actions + Vercel，提交即部署。但自动化不等于没有保险：
yaml

.github/workflows/deploy.yml 片段
- name: Deploy to Vercel
  run: vercel --prod

- name: Notify on failure
  if: failure()
  run: |
    curl -X POST $SLACK_WEBHOOK \
      -d '{"text":"部署失败: ${{ github.sha }}"}'

必须有的机制：
1.)
自动回滚：Vercel 自带，但数据库迁移必须可逆——用  down  脚本，不用  ALTER TABLE DROP COLUMN

2. )
健康检查：部署后自动调  /health ，非 200 则告警

3. )
灰度发布：Vercel 按地区/百分比灰度，小项目足够用

5. 监控：用户报错前，你先知道
独立开发没有测试团队，生产环境就是测试环境。监控必须覆盖：
表格
层级
工具
看什么
性能
Vercel Analytics / Lighthouse
Core Web Vitals，首屏 < 1.5s
错误
Sentry
未捕获异常、Source Map 定位到行
业务
自建简单看板
关键路径转化率、支付失败率
日志
Logflare / Datadog
慢查询、第三方 API 延迟
一个实用技巧：在关键业务路径埋点，不要等用户反馈"支付不了"才发现支付接口挂了。

最后
独立开发的技术决策，核心就一句话：选择让你睡得好觉的方案，不是让你炫技的方案。
复杂架构、自研中间件、微服务——这些在团队里有人兜底，一个人搞就是给自己挖坑。
以上5条，全是我的真坑。希望能帮你少踩几个。

有问题直接评论区丢代码，看到就回。

原创

0 cool

暂无评论，来说两句吧

登录后评论

系统节点

兴趣节点全部

独立开发一年，我总结了5条「不废话」的技术原则

评论 (0)

系统节点

兴趣节点 全部

独立开发一年，我总结了5条「不废话」的技术原则

评论 (0)

兴趣节点全部