Node.js删除产品关联图片时，应选异步fs.unlink还是同步fs.unlinkSync？

直接给结论 #

• 优先选用Promise封装的异步fs.unlink，和你当前接口的async/await代码风格匹配
• 不推荐使用同步的fs.unlinkSync，除非你的服务是完全本地运行的低并发小工具

选型的核心原因 #

为什么异步unlink更适配当前场景 #

• Node.js基于单线程事件循环运行，fs.unlinkSync是同步阻塞API，执行时会卡住整个事件循环的处理流程。服务并发量上来后，哪怕单次磁盘IO只耗几毫秒，累计的阻塞也会大幅拉低所有接口的响应速度，完全违背Node.js的性能设计逻辑。
• 目前官方提供的fs/promises模块已经把回调风格的unlink封装成了可直接await的Promise，不需要自己手写回调转Promise的代码，可以无缝嵌入你现有的try/catch错误处理结构。
• 文件删除过程中遇到的权限不足、路径不存在等异常，可以被统一捕获，和数据库删除的错误处理逻辑打通。

为什么尽量不要用fs.unlinkSync #

• 同步方法一旦抛出未捕获的错误，会直接导致整个Node进程崩溃，故障风险远高于异步API。
• 同步阻塞的特性会让服务的并发处理能力断崖式下降，哪怕是几百QPS的小流量场景也可能出现响应超时。

适配现有代码的改造示例 #

注意：你现有代码的逻辑有个顺序问题——先删了数据库的产品记录，根本拿不到对应图片的存储路径，必须调整查询顺序：先查出产品的完整信息拿到图片路径，再删数据库记录，最后删文件。
改造后的完整代码参考：

// 引入fs模块的Promise版本，无需手动封装回调
const fs = require('fs/promises')
const path = require('path')

module.exports.deleteProduct = async (req, res, next) => {
    const productId = req.body.productId
    try {
        // 先查询待删除的产品记录，拿到图片存储路径
        const product = await Product.findByPk(productId)
        if (!product) {
            return res.status(404).json({ message: '待删除产品不存在' })
        }
        // 拼接图片在服务器上的绝对路径，根据你实际的上传目录调整
        const imageAbsPath = path.join(__dirname, 'static/upload', product.imageUrl)

        // 执行核心的数据库删除逻辑
        await Product.destroy({ where: { id: productId } })

        // 数据库删除成功后，再异步删除图片文件
        // 单独包一层try/catch，避免文件删除失败影响核心接口的返回
        try {
            await fs.unlink(imageAbsPath)
        } catch (fileError) {
            // 仅记录错误日志，不需要把错误返回给前端，这类残留文件可以后续通过定时任务批量清理
            console.log('产品关联图片删除失败：', fileError)
        }

        res.status(200).json({ product })
    } catch (err) {
        console.log('删除产品异常：', err)
        res.status(500).json({ message: '服务器内部错误，删除失败' })
    }
}

落地实操的小提示 #

• 不要把文件删除操作放在数据库删除之前执行，否则一旦数据库删除失败，已经被删掉的图片就无法找回了。
• 不要把文件删除的错误作为接口返回的失败条件：毕竟文件存储属于非核心的附属资源，只要数据库里的产品记录删除成功，就应该给前端返回成功，图片残留不影响核心业务流程。
• 如果一个产品对应多张图片，可以把批量删除的逻辑放到独立的后置队列里执行，不需要让接口等待所有文件删除完成再响应。

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