GoLang使用FileServer服务目录时修改被服务文件阻塞是否为预期行为

这不是Go标准库http.FileServer的预期行为。

• 标准库http.FileServer的实现逻辑是：每次收到静态文件请求时，才调用os.Open临时打开对应文件，读取内容返回后就会立即关闭文件句柄，不会长期持有文件资源，也不会对文件加独占锁，正常运行过程中完全允许修改被服务的静态文件，修改完成后下一次请求就会返回更新后的内容。
• 你遇到的写入阻塞问题，大概率来自两类场景：
  1. 运行环境是Windows系统：Windows的文件锁机制和类Unix系统存在差异，如果存在高频持续的index.html请求，可能会出现短时间的写入阻塞，但不会永久阻塞到服务停止。如果是永久阻塞，优先排查你自己的代码是否在其他位置对该文件操作加了互斥锁且未正确释放，或者存在其他进程长期持有该文件的读句柄。
  2. 你提供的写文件代码存在隐含问题：打开文件时仅指定了os.O_RDWR标识，如果你追加写入的过程中其他逻辑修改了文件长度，Seek(-15, 2)的偏移计算会出错，虽然不会直接导致阻塞，但可能引发写入内容异常。如果确实是WriteString调用永久阻塞，建议在操作文件的各步骤增加埋点日志，确认是卡在打开文件、偏移定位还是写入阶段，再针对性排查锁竞争问题。

你可以给FileServer套一层简单的中间件，打印文件打开、关闭的时间点，和你写文件操作的日志对比，就能确认是否是FileServer持有文件句柄导致的阻塞。

内容的提问来源于stack exchange，提问作者m0ur