Node.js异步函数中使用try-finally安全转移文件句柄所有权的疑问

我来帮你拆解这个有点反直觉的问题，核心还是绕着文件句柄的单一所有权规则和异常场景下的资源安全来的。先把关键矛盾点和逻辑理清楚：

原代码的隐藏bug #

先回顾你贴的原始serveStaticFile实现：

async function serveStaticFile(path: string, req: HTTPReq): Promise<HTTPRes> {
  let fp: null | fs.FileHandle = null;
  try {
    // omitted...
    const reader = readerFromStaticFile(fp, size);
    fp = null;
    return {code: 200, headers: [], body: reader};
  } catch(exc) {
    return resp404("File not found");
  } finally {
    await fp?.close();
  }
}

作者提到的风险是：如果readerFromStaticFile抛出异常（虽然作者说它不会，但假设极端情况会），会导致文件被关闭两次。

原因很明确：

1. 当readerFromStaticFile抛出异常时，fp = null这行代码根本没机会执行，fp还是指向打开的文件句柄。
2. 异常会触发外层catch块返回404，之后进入外层finally块执行await fp?.close()——但根据规则，readerFromStaticFile如果抛出异常，它自己应该已经关闭了文件（因为它当时临时持有所有权），这就导致了重复关闭文件句柄的bug。

作者推荐的内部try-finally为什么能解决问题 #

作者建议的改进写法是在readerFromStaticFile调用外层套一个内部try-finally：

try {
  const reader: BodyReader = readerFromStaticFile(fp, size);
  return {code: 200, headers: [], body: reader};
} finally {
  fp = null; // 无论成功失败，都放弃所有权
}

这看起来反直觉，但核心是确保无论readerFromStaticFile成功还是失败，serveStaticFile都会立刻放弃文件的所有权：

• 如果readerFromStaticFile成功执行：内部try块正常返回，finally里把fp设为null，外层finally的fp?.close()就不会执行——所有权已经安全转移给BodyReader，由它负责后续关闭。
• 如果readerFromStaticFile抛出异常：内部finally会先把fp设为null，之后异常会冒泡到外层的catch块，而外层finally的fp?.close()因为fp是null，也不会执行——这就避免了重复关闭，因为此时readerFromStaticFile已经在异常时自己关闭了文件，我们不能再插手。

再捋一遍所有权的流转逻辑 #

1. 初始状态：serveStaticFile打开文件，持有fp，是唯一所有者，负责关闭。
2. 调用readerFromStaticFile：
   • 若函数成功：所有权转移给BodyReader，serveStaticFile必须把fp设为null，放弃所有权，不再负责关闭。
   • 若函数抛出异常：readerFromStaticFile作为临时持有者，必须自己关闭文件，serveStaticFile也要把fp设为null，避免后续重复关闭。
3. 内部try-finally的作用就是把fp = null这个“放弃所有权”的操作，从“仅成功时执行”变成“无论成功失败都执行”，彻底堵住异常场景下的重复关闭漏洞。

这样整个流程就严格遵守了单一所有权规则：任何时刻只有一个主体负责文件的关闭，不会出现多个主体同时持有有效句柄导致的重复关闭问题。

内容来源于stack exchange