本文详解为何 fs.readFileSync 无法配合回调函数使用，导致数组未被正确填充，并提供基于同步读取的简洁、可靠解决方案。
本文详解为何 `fs.readfilesync` 无法配合回调函数使用，导致数组未被正确填充，并提供基于同步读取的简洁、可靠解决方案。
在 Node.js 中，fs.readFileSync() 是一个同步阻塞式方法，它会立即读取文件内容并直接返回字符串（或 Buffer），而不是接受回调函数——这与异步版本 fs.readFile() 的签名有本质区别。原代码中错误地为 readFileSync 传入了第三个参数 (err, data) => {...}，该回调永远不会被执行，因此 names.push(name) 实际上从未运行，最终返回的 names 始终为空数组。
✅ 正确做法：用 map() + readFileSync 构建新数组
由于 readFileSync 返回的是数据本身，我们应直接捕获其返回值，并在 .map() 中完成解析与提取：
const names = files.map((fileName) => {
try {
const data = fs.readFileSync(fileName, 'utf8'); // ✅ 同步读取，直接返回字符串
const parsedData = JSON.parse(data); // ✅ 解析 JSON
return parsedData.toDoListName; // ✅ 提取字段并返回
} catch (err) {
console.error(`Failed to read or parse ${fileName}:`, err.message);
return null; // 或抛出错误、跳过该文件，按需处理
}
}).filter(name => name !== null); // 可选：过滤掉解析失败的项
⚠️ 注意事项
-
不要混用同步/异步风格：
readFileSync不支持回调；若需异步处理（如高并发、大量文件），应改用fs.promises.readFile配合Promise.all()； -
异常处理至关重要：任意文件损坏或 JSON 格式错误都会导致
JSON.parse()抛出异常，进而中断整个map()流程，因此务必包裹try...catch； -
路径安全性：示例中硬编码了邮箱路径（如
./ToDoLists/[email protected]/），生产环境应校验路径合法性，防止目录遍历攻击（如使用path.normalize()+ 白名单校验）； - 性能考量：同步 I/O 在单次请求中处理少量文件可接受；但若文件数较多（如 >100），建议迁移至异步批量读取以避免阻塞事件循环。
✅ 最终整合到路由中的推荐写法
app.get("/overview", (req, res) => {
const emailDir = "./ToDoLists/[email protected]/";
const getFiles = (dir) => {
const entries = fs.readdirSync(dir);
return entries.flatMap(entry => {
const fullPath = path.join(dir, entry);
return fs.statSync(fullPath).isDirectory()
? getFiles(fullPath)
: [fullPath];
});
};
try {
const files = getFiles(emailDir);
const names = files
.map(file => {
const data = fs.readFileSync(file, 'utf8');
return JSON.parse(data).toDoListName;
})
.filter(Boolean); // 移除 undefined / null
res.json(names);
} catch (err) {
console.error("Overview route error:", err);
res.status(500).json({ error: "Failed to load todo list names" });
}
});
通过以上重构，names 数组将准确包含每个 JSON 文件中 toDoListName 字段的值，逻辑清晰、健壮且符合 Node.js 同步 I/O 的正确使用范式。
