博客 | 技术作品集

用 Node.js 与 Express 构建可上线的 REST API

Tue, 10 Dec 2024 00:00:00 +0000

很多 API 在本地开发阶段看起来没有问题，但一旦进入真实环境，就会暴露出认证、校验、错误处理和文档缺失的问题。真正可上线的 API，重点不是“能跑”，而是“能维护、能扩展、能排查”。

建议至少把配置、路由、控制器、服务层、中间件和校验逻辑拆开。这样做的价值不是形式上的分层，而是让业务逻辑不会散落在每个接口文件里，后续测试和重构都更可控。

接口一多，权限模型就会迅速复杂。把令牌解析、身份校验、角色判断放到中间件层处理，能避免大量重复代码，也方便统一返回错误格式。

不要在每个接口里各写一套 try/catch。更合理的方式是定义业务错误类型，再通过统一错误处理中间件输出稳定的状态码和错误消息。这样做对日志检索、监控告警和前端联调都更友好。

参数校验应当在进入业务逻辑之前完成，包括 body、query 和 params。不论使用 Zod、Joi 还是其他方案，关键是把校验规则显式化，避免非法数据进入数据库或核心逻辑。

接口文档至少需要说明输入、输出、错误码和鉴权方式。测试不一定一开始就追求很高覆盖率，但登录、权限、关键写操作和异常分支至少要被覆盖。

如果你把目录组织、鉴权、校验、错误处理和文档这几件事从一开始就做好，后续增加业务功能会顺畅很多，API 的维护成本也会低不少。

Fri, 22 Nov 2024 00:00:00 +0000

React 项目在体量增长之后，性能问题往往不是单点爆炸，而是很多小问题叠加出来的。真正有效的优化，通常从定位问题开始，而不是盲目加 memo 或者到处缓存。

在动手之前，先用浏览器性能面板和 React DevTools Profiler 看清楚是哪里慢。常见问题包括不必要的重复渲染、超大列表、昂贵计算、首包过大以及 Context 设计不合理。

如果父组件频繁更新，而子组件又很多，就很容易造成整片区域一起重渲染。这个时候应先检查状态放置位置是否合理，再决定是否使用 memo、拆分组件或调整数据流。

有些页面卡，是因为筛选、排序、格式化数据太重；有些则是 DOM 节点太多。前者更适合做缓存或预计算，后者更适合做列表虚拟化、分页或懒加载。

当列表长度上千时，一次性渲染全部节点通常是不划算的。无论用虚拟列表还是分段加载，本质都是减少首屏和滚动过程中的真实 DOM 数量。

性能不只是交互速度，还包括首屏加载。对大型页面做按需加载、拆包和资源延迟加载，通常能比微调组件更直接地改善用户感知。

React 性能优化最重要的原则是有证据地做决策。先找到瓶颈，再选择最小但有效的改动，通常比“全局优化一遍”更稳，也更不容易引入新的复杂度。

Tue, 15 Oct 2024 00:00:00 +0000

Docker 的价值不只是“把应用跑起来”，而是让开发、测试和生产环境尽量保持一致。只要项目涉及多人协作、依赖较多或部署频繁，容器化几乎都会带来明显收益。

基础镜像尽量精简，工作目录、依赖安装、源码复制和启动命令要保持清晰。开发阶段能跑不代表生产环境合适，真正上线时更应关注镜像体积、构建速度和安全边界。

把“构建产物”和“运行环境”拆开，通常可以显著缩小最终镜像体积。对于前端项目、Node 服务或 Go 服务，这都是很常见也很有效的优化手段。

数据库连接、第三方密钥、JWT 密钥这类配置都应该通过环境变量注入。把配置和镜像解耦之后，部署到不同环境会简单很多，也更安全。

本地可以使用 docker compose 同时拉起应用、数据库和缓存，方便调试；生产环境则更关注启动顺序、健康检查、日志输出、资源限制和自动重启策略。

容器化之后，不代表问题会自动消失。日志、健康检查、错误告警、资源监控这些能力仍然要补齐，否则线上问题依旧很难排查。

容器化最核心的收益，是把“环境差异”这个问题尽量收敛掉。只要同时兼顾镜像优化、配置管理和运行时观测，Docker 会是一套非常稳妥的交付基础设施。