Node.js 服务在 Debian 上跑久了，日志文件通常会持续增长。要是不提前安排轮转策略，轻则排查麻烦，重则把磁盘空间吃满。本文按部署时最常见的流程，把 logrotate 的安装检查、Node.js 日志前提、配置写法和验证方法串起来，方便你快速判断这套方案是否适合当前服务。
先确认 Debian 是否已安装 logrotate
Debian 系统里很多环境已经预装了 logrotate，但正式配置前，最好还是先确认一下。没有安装的话，先更新包索引，再补上这个工具：
sudo apt-get update
sudo apt-get install logrotate这一步的目的很直接：先把日志轮转能力准备好，后面的配置文件才能真正生效。
Node.js 日志输出方式为什么重要
在开始写轮转规则前，要先看 Node.js 应用现在是怎么输出日志的。按文中的前提，应用应尽量使用标准输出和标准错误，也就是常见的 stdout 和 stderr，例如直接调用 console.log()、console.error()。
这样做的好处是，日志流向更规范，后续交给系统层或外部工具处理时更容易接上。如果你的应用已经把日志写进了自定义文件路径，也不是不能轮转，只是配置时必须明确指定那个实际日志文件，而不能照搬示例路径。
换句话说，logrotate 负责的是“已有日志文件怎么轮转”，而不是替你决定应用把日志写到哪里。正式配置前，先把日志文件位置和写入方式弄清楚，后面就不会出偏差。
在 /etc/logrotate.d/ 中创建配置文件
Debian 上最常见的做法，是在 /etc/logrotate.d/ 目录下为目标服务单独放一个配置文件。文中的示例名是 nodejs：
sudo nano /etc/logrotate.d/nodejs单独建文件的好处是清晰、好维护。以后你要调整 Node.js 服务的日志策略，不需要去翻大而杂的全局配置，直接修改这一个文件即可。
配置内容怎么写，各参数分别代表什么
创建好文件后，可以写入下面这段配置：
/path/to/your/nodejs/app.log {
daily
rotate 7
compress
missingok
notifempty
create 0640 root adm
}这里最关键的是第一行路径。/path/to/your/nodejs/app.log 只是占位写法，实际使用时要换成你自己的日志文件路径，否则规则不会落到目标文件上。
轮转频率与保留周期
daily：表示每天轮转一次。rotate 7：表示保留最近 7 天的日志备份。
这两个参数组合起来，适合大多数常规业务服务：轮转周期固定，回溯时间也比较明确。如果你的日志量特别大，后续也可以改成按大小轮转，或者调整保留数量。
压缩与空间控制
compress：轮转后的旧日志会自动压缩成gz格式。
这项配置的意义主要在节省磁盘空间。对持续运行的 Node.js 服务来说，旧日志保留是有必要的，但原样堆着通常很占空间，压缩后更适合长期保存。
异常情况与空文件处理
missingok：日志文件不存在时不报错，直接跳过。notifempty：如果日志文件是空的，就不执行轮转。
这两个选项属于比较实用的“容错项”。它们可以减少无意义报错，也避免对空日志做多余处理，适合放进大多数生产环境配置里。
轮转后新文件如何创建
create 0640 root adm：轮转后立即新建一个空日志文件，权限为0640，属主是root，属组是adm。
这一项决定了新日志文件的权限和归属。是否能直接沿用示例里的 root adm，要看你的实际运行环境。如果 Node.js 进程写入权限和这里不匹配，就需要按服务账户做调整，否则新文件生成后可能会出现应用无法继续写日志的问题。
如何手动触发并验证轮转是否生效
配置保存后，logrotate 会按照既定规则每天自动执行。为了避免等到第二天才发现配置有误，通常会先手动强制跑一遍：
sudo logrotate -f /etc/logrotate.d/nodejs这个命令会立即按配置执行一次轮转，适合用来确认几件事：配置文件能否正常解析、目标日志是否真的被轮转、旧日志是否按预期压缩，以及新日志文件是否成功创建。
如果这一步通过，说明整套基础配置已经能跑起来。后面要做的，多半只是根据业务情况微调参数，例如按大小轮转、保留更多历史文件，或者把多个日志文件一起纳入同一份规则里。
这套方案适合什么场景
对于部署在 Debian 上、日志持续写入的 Node.js 服务，这是一套足够轻量、也足够实用的基础方案。它解决的不是复杂日志平台建设，而是最常见的本地日志膨胀问题：定期轮转、压缩旧文件、控制保留时间，并减少手工清理的负担。
如果你的当前需求就是先把日志管住，不让单个文件无限变大，那么这份配置已经能直接作为起点使用。后续再根据日志量、权限模型和运维习惯继续细化即可。
