背景为什么我要重复造轮子做独立产品最消耗人的不是写业务代码而是每次都要从零搭一遍登录注册、会话管理、支付回调、后台统计、部署脚本……市面上的启动模板大多是 Next.js Prisma TypeScript 全家桶依赖几百个光搭环境就一个周末。于是我做了个反向选择只用 Node.js 内置模块零 npm 依赖、零构建步骤整个服务端约 2000 行。本文把这个套件的核心实现拆开讲源码已开源MIT。一、为什么零依赖是可行的关键判断单机 轻量场景Node 内置模块已经够用了。需求内置模块方案HTTP 服务node:http密码哈希node:crypto的scryptSyncOWASP 推荐 KDF会话签名node:crypto的createHmacRSA 验签node:crypto的createVerify静态文件node:fscreateReadStream数据存储JSON 文件 原子写入临时文件 renameSync代价是不能多实例部署、没有复杂查询能力。但对一个人 一台 50 元/月服务器这个规模完全够用而且换来了零供应链风险和极低的维护成本。二、几个关键实现1密码哈希scrypt 而不是 bcryptconstSCRYPT{N:16384,r:8,p:1,keylen:64};functionhashPassword(password){constsaltcrypto.randomBytes(16);constderivedcrypto.scryptSync(password,salt,SCRYPT.keylen,SCRYPT);returnscrypt$${SCRYPT.N}$${SCRYPT.r}$${SCRYPT.p}$${salt.toString(hex)}$${derived.toString(hex)};}校验时用crypto.timingSafeEqual防时序攻击登录失败也要执行一次哈希防邮箱枚举。2会话服务端只存 token 哈希cookie 里放 HMAC 签名的 token服务端只存sha256(token)。这样即使数据库泄露攻击者也无法用哈希值直接登录不能回放。3JSON 数据库的原子写入直接writeFileSync有断电写坏文件的风险正确姿势是写临时文件再renameconsttmpthis.file.tmp-process.pid;fs.writeFileSync(tmp,snapshot,utf8);fs.renameSync(tmp,this.file);// 同分区 rename 是原子操作4Webhook 验签三个必须踩对的细节对接 Waffo Pancake 收款时我在这上面栽过跟头记录下来避免后人重复签名在X-Waffo-Signature头格式是t时间戳,v1Base64签名不是裸 base64验签对象是${时间戳}.${原始请求体}不是只有请求体必须用未经解析的原始 body—— 先JSON.parse再JSON.stringify会因为键顺序/空格差异导致验签失败。constsigparseWaffoSignature(req.headers[x-waffo-signature]);// { t, v1 }constverifycrypto.createVerify(RSA-SHA256);verify.update(${sig.t}.${rawBody});// 注意这里verify.end();constokverify.verify(publicKeyPem,sig.v1,base64);还有两个部署层面的坑时间戳容差要覆盖平台的重试窗口Waffo 重试会沿用最初的时间戳最长跨 8 小时容差设 45 分钟会误拒迟到的重试测试与生产是两套密钥代码里要同时支持多把公钥切换环境时不会漏收通知。三、部署一条命令bashdeploy/deploy-aliyun.sh脚本自动装 Node 20、注册 systemd 开机自启、启动服务。配套的 Docker / nginx / 每日备份脚本也都在仓库里。四、源码与体验完整源码MIT 免费版https://github.com/200800610Pp/goship线上 demohttps://getgoship.com如果你也在做独立产品欢迎交流你觉得零依赖是务实还是倒退评论区聊聊。 
长河君 · 2026/10/19 2:16:44 · 阅读 1.2k 零依赖 Node.js 手撸 SaaS 启动套件：2000 行代码搞定登录、支付、后台（附完整源码）
背景为什么我要重复造轮子做独立产品最消耗人的不是写业务代码而是每次都要从零搭一遍登录注册、会话管理、支付回调、后台统计、部署脚本……市面上的启动模板大多是 Next.js Prisma TypeScript 全家桶依赖几百个光搭环境就一个周末。于是我做了个反向选择只用 Node.js 内置模块零 npm 依赖、零构建步骤整个服务端约 2000 行。本文把这个套件的核心实现拆开讲源码已开源MIT。一、为什么零依赖是可行的关键判断单机 轻量场景Node 内置模块已经够用了。需求内置模块方案HTTP 服务node:http密码哈希node:crypto的scryptSyncOWASP 推荐 KDF会话签名node:crypto的createHmacRSA 验签node:crypto的createVerify静态文件node:fscreateReadStream数据存储JSON 文件 原子写入临时文件 renameSync代价是不能多实例部署、没有复杂查询能力。但对一个人 一台 50 元/月服务器这个规模完全够用而且换来了零供应链风险和极低的维护成本。二、几个关键实现1密码哈希scrypt 而不是 bcryptconstSCRYPT{N:16384,r:8,p:1,keylen:64};functionhashPassword(password){constsaltcrypto.randomBytes(16);constderivedcrypto.scryptSync(password,salt,SCRYPT.keylen,SCRYPT);returnscrypt$${SCRYPT.N}$${SCRYPT.r}$${SCRYPT.p}$${salt.toString(hex)}$${derived.toString(hex)};}校验时用crypto.timingSafeEqual防时序攻击登录失败也要执行一次哈希防邮箱枚举。2会话服务端只存 token 哈希cookie 里放 HMAC 签名的 token服务端只存sha256(token)。这样即使数据库泄露攻击者也无法用哈希值直接登录不能回放。3JSON 数据库的原子写入直接writeFileSync有断电写坏文件的风险正确姿势是写临时文件再renameconsttmpthis.file.tmp-process.pid;fs.writeFileSync(tmp,snapshot,utf8);fs.renameSync(tmp,this.file);// 同分区 rename 是原子操作4Webhook 验签三个必须踩对的细节对接 Waffo Pancake 收款时我在这上面栽过跟头记录下来避免后人重复签名在X-Waffo-Signature头格式是t时间戳,v1Base64签名不是裸 base64验签对象是${时间戳}.${原始请求体}不是只有请求体必须用未经解析的原始 body—— 先JSON.parse再JSON.stringify会因为键顺序/空格差异导致验签失败。constsigparseWaffoSignature(req.headers[x-waffo-signature]);// { t, v1 }constverifycrypto.createVerify(RSA-SHA256);verify.update(${sig.t}.${rawBody});// 注意这里verify.end();constokverify.verify(publicKeyPem,sig.v1,base64);还有两个部署层面的坑时间戳容差要覆盖平台的重试窗口Waffo 重试会沿用最初的时间戳最长跨 8 小时容差设 45 分钟会误拒迟到的重试测试与生产是两套密钥代码里要同时支持多把公钥切换环境时不会漏收通知。三、部署一条命令bashdeploy/deploy-aliyun.sh脚本自动装 Node 20、注册 systemd 开机自启、启动服务。配套的 Docker / nginx / 每日备份脚本也都在仓库里。四、源码与体验完整源码MIT 免费版https://github.com/200800610Pp/goship线上 demohttps://getgoship.com如果你也在做独立产品欢迎交流你觉得零依赖是务实还是倒退评论区聊聊。