Node.js 应用长期跑在 Debian 服务器上，日志文件越积越多几乎是迟早会遇到的问题。真正需要解决的，不只是“删掉旧日志”，而是根据当前场景判断：是临时清理磁盘、建立系统级自动轮转，还是直接在应用层把日志策略提前管起来。下面按这三条路径分别展开，你可以据此选择最省事、也最适合现有部署方式的做法。

手动删除：适合临时应急清理

如果你已经知道日志文件所在目录，最直接的办法就是手动删除。对于一次性的磁盘清理，这种方式见效最快。

例如，日志位于 /var/log/my-node-app/ 时，可以执行：

sudo rm -rf /var/log/my-node-app/*.log

这条命令会直接删除匹配到的 .log 文件，属于永久删除操作。实际执行前，最好先确认两件事：一是这些日志已经备份，二是当前排障或审计不再依赖它们。对于生产环境，这种方式更适合作为临时止血手段，而不是长期管理方案。

用 logrotate 自动轮转日志

如果你不想反复手动清理，logrotate 往往是 Debian 上更稳妥的选择。它可以按照时间或体积规则自动轮转日志，对旧日志进行压缩、保留和清理，比较适合长期运行的 Node.js 服务。

安装 logrotate

如果系统里还没有安装，可以先执行：

sudo apt-get install logrotate

为 Node.js 日志编写轮转配置

可以创建一个独立配置文件，例如 /etc/logrotate.d/my-node-app，写入下面的规则：

/var/log/my-node-app/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 root adm
}

这份配置对应的含义比较明确：

• daily：每天轮转一次；
• rotate 7：保留最近 7 轮日志；
• compress：旧日志自动压缩；
• missingok：日志不存在时不报错；
• notifempty：空日志文件不轮转；
• create 0640 root adm：轮转后创建新日志文件，并指定权限和属主属组。

如果你的应用写日志频率更高，或者保留周期更长，可以在这份配置的基础上继续调整参数。

确认轮转任务是否生效

Debian 系统一般已经为 logrotate 配好了定时执行任务，但在上线配置后，手动触发一次会更直观：

sudo logrotate -f /etc/logrotate.conf

这样可以立即验证配置是否能正常工作，也方便你检查日志是否按预期被轮转和压缩。

在 Node.js 应用里直接控制日志

如果你希望把日志大小、数量和轮转策略放到应用代码层统一管理，那么使用日志库会更灵活。原文提到的 winston 和 bunyan，都属于这类常见选择。

这条路线的优势在于，日志策略可以跟随应用一起部署和维护，不必完全依赖系统级工具。对于开发阶段就想提前规范日志输出、区分不同级别日志，或者未来还要接入集中式日志平台的项目，这种方式通常更容易扩展。

不过，应用内方案并不一定取代系统工具。在很多服务器环境里，应用层负责生成规范日志，系统层再用 logrotate 做统一保留和清理，反而是更常见的组合。

三种做法怎么选

如果你只是临时发现磁盘被日志占满，手动删除最直接；如果你在维护一台长期运行的 Debian 服务器，logrotate 往往是默认优先级更高的方案；如果你希望从开发阶段就把日志数量、大小和策略纳入应用设计，日志库会提供更细的控制能力。

换句话说，这三种方法并不冲突，而是分别对应不同层级的问题：应急处理、系统运维和应用治理。先明确自己要解决的是哪一类问题，再决定采用哪一种，日志管理会更省心。