182 篇博文 含有标签「后端开发」

很多后台项目在权限设计上都会经历一个阶段: 一开始觉得只要登录就够了，后来页面越来越多、角色越来越多，接口权限判断开始四处散落。

Feathers.js 写着写着，大家迟早会遇到一个现实问题: 错误到底该在 hook 层拦，还是在 service 里抛，还是统一让框架接住以后再返回前端。

2021 年如果还在继续做 Node.js 后端，会明显感觉到一个趋势: 大家不再满足于“能把接口写出来”这件事了，而是开始追求更快搭后台、更容易扩展认证、更自然接入实时能力。

刚开始接触 Feathers.js 时，很多人会先被 service 和 hook 吸引，但真正把项目落地到后台管理系统，很快就会遇到一个更实际的问题: 登录链路到底怎么搭才不乱。

Go 标准库里的 encoding/json 已经够用了，平时做接口、配置读取、消息体解析，大多数场景都离不开它。问题在于，很多初学阶段写出来的 JSON 代码“能跑”但并不稳。真正进入接口联调或者服务之间互相调用时，字段命名、默认值、空值含义这些细节很快就会冒出来。

刚开始写 Go 的时候，遇到文本拼接最容易想到的还是 +。代码少时当然没问题，但一旦进入循环、日志拼接、模板前处理或者接口响应组装，这种写法很快就会让代码既不清晰，也不够稳妥。真正开始做一些小工具之后，我发现自己最常用的其实不是花哨技巧，而是把 strings.Builder 和 bytes.Buffer 的边界分清楚。

Go 学久一点以后，很多人都会记住一句话：interface 要小。但真到项目里，接口问题往往不是“大或小”这么简单，而是抽象出现得太早。实现只有一种、调用方式还没定稳，就先定义一堆 UserService、OrderRepository 接口，最后只会让代码多一层跳转。

刚开始写 Go 的时候，很多人会觉得错误处理很重复：每层都要判断 err != nil，看起来很机械。可真到了线上排查问题时，最怕的不是判断多，而是最后拿到的错误只有一句 “open failed” 或 “query error”，根本不知道是哪一步出的事。

很多人刚写 Go 项目时，最有安全感的动作就是先把目录搭完整：controller、service、dao、model、utils 先分好，觉得以后扩展会方便。可项目在功能还不稳定的时候，包分得太细，往往比全写在一个地方更容易把自己绕进去。

前端开发者刚转到 Node.js 时，经常会在异步这里卡住。页面脚本里也有事件和回调，但放进服务端请求处理后，感受会更强，因为浏览器正在等你返回结果，流程一下就变得更有压力。