198 篇博文 含有标签「Node.js」

第一次把 LevelDB 用进项目时，很容易被它的简单和直接打动：本地 KV、读写快、嵌入式、不用额外起服务。可也正因为它太像一个“很方便的本地抽屉”，很多人会自然把它当缓存来用，然后默认它应该顺便帮你解决缓存该有的那套问题。

现在大家一提 Docker 镜像优化，很容易先想到多阶段构建。但 2017 年那会儿，很多团队日常还没有把这套玩法完全用顺。想让镜像体积别太夸张，往往还是靠一些更基础、也更朴素的习惯。

用 glob 做批处理时，大家通常会先想“我该怎么把目标文件匹配出来”。
可 2017 年我自己写这类脚本越来越多之后，反而最警惕另外一件事：是不是把不该处理的生成目录也一起扫进来了。

第一次在 Node.js 脚本里用 glob，会有一种很爽的感觉：以前得自己递归目录、判断后缀，现在一条模式就能把文件找出来。可真把它用进构建脚本、批处理脚本、资源扫描脚本以后，就会发现路径这件事比模式本身更容易出问题。

早些年排查线上日志，很多人的第一反应都是 tail -f。我也一样，因为它直接、顺手，而且大多数教程都是这么教的。可 2017 年之后，随着 systemd 越来越常见，我慢慢发现，如果 Node 服务本身就是被 systemd 接管的，只盯着 tail 其实会漏掉很多关键信息。

Docker Compose 刚开始用的时候特别有吸引力，因为你很快就能把 Node.js 服务、Nginx 代理、数据库一起拉起来。可 2017 年我自己真正把它放进开发流程后，最大的感受不是“真方便”，而是“边界太容易乱了”。

Nginx 反向代理 Node 服务时，很多问题表面上都像“接口有 bug”。
可 2017 年我自己在处理代理和部署问题时，越来越多时候发现，根因其实不在业务代码，而在请求经过 Nginx 之后，有些关键信息没有被完整传下去。

问一个很现实的问题：为什么很多 Express 项目都有认证中间件、日志中间件、跨域中间件，却偏偏把错误处理中间件留到最后才补？
我的答案是，因为它不像“功能”那样立刻可见，只有出问题时你才会想起它。

图片上传这类接口最容易在需求讨论里被说成一句话：选文件，传上去，返回地址。
可 2016 年我在做这类功能时越来越明显地感觉到，一个上传接口如果一开始只关注“体验顺不顺”，却没有先限制大小、类型和错误边界，后面出问题会非常频繁。

2014 年前后，Node.js 配 Redis 是很常见的一套轻量组合。大家一开始都觉得 Redis 上手快，set、get 会用就能干活，但真把它放进登录态、验证码、计数器、页面缓存之后，问题很快就来了：key 越堆越多，过期时间各写各的，最后自己都看不懂线上到底存了什么。