错误分析修复

错误原因分析

• Node.js 默认把 .js 文件按照 CommonJS 解析。你的 package.json 没有设置 "type":"module"，所以 index.js 被当作 CommonJS 文件来执行。CommonJS 环境下不允许使用 import ... 语法，因此报错 “Cannot use import statement outside a module”。
• 项目中还存在 utils.cjs（CommonJS）与 index.js（使用了 ESM 的 import）混用，进一步导致运行方式不一致。

下面给出两套可行且互斥的修复方案，请选择其一并统一全项目的模块系统。

方案A：统一为 ESM（现代模块，推荐） 目标：在整个项目中使用 ESM（import/export），并避免 CommonJS。

调整步骤

1. 修改 package.json，添加 type 字段 { "name": "demo", "version": "1.0.0", "type": "module", "main": "index.js", "scripts": { "start": "node index.js" } }

2. 将 utils.cjs 改为 ESM 文件 utils.js（或保留文件名但内容改为 ESM），并使用 export 文件：utils.js export function sum(a, b) { return a + b }

3. 修正 index.js，确保 ESM 导入语法正确且包含文件扩展名 文件：index.js import express from 'express' import { readFileSync } from 'fs' import { sum } from './utils.js'

const app = express() app.get('/health', (_, res) => res.send('ok')) app.listen(3000, () => console.log('server started'))

4. 运行 npm start

注意事项（ESM）

• 在 ESM 中导入本地文件必须带扩展名（如 './utils.js'）。
• Node 版本建议 >= 14.13（更推荐 >= 16）。Express 作为 CommonJS 包，默认在 ESM 中可以通过 import express from 'express' 正常使用。
• 避免使用 module.exports/require 等 CommonJS 语法。

方案B：统一为 CommonJS（传统模块） 目标：在整个项目中使用 CommonJS（require/module.exports），并移除/避免 ESM 语法。

调整步骤

1. 保持或移除 package.json 的 type（不要设置 "type":"module"） { "name": "demo", "version": "1.0.0", "main": "index.js", "scripts": { "start": "node index.js" } }

2. 将 index.js 改为 CommonJS 语法（使用 require） 文件：index.js const express = require('express') const { readFileSync } = require('fs') const { sum } = require('./utils.js')

const app = express() app.get('/health', (_, res) => res.send('ok')) app.listen(3000, () => console.log('server started'))

3. 将 utils.cjs 改名为 utils.js（或保留 .cjs 也可），统一使用 module.exports 文件：utils.js module.exports = { sum(a, b) { return a + b } }

4. 运行 npm start

注意事项（CommonJS）

• 不要在任何 .js 文件里使用 import/export。
• 如果保留 .cjs 扩展名也可以，但为了统一与简化，建议改为 utils.js。

补充建议

• 两种方案不要混用。选择其一后，统一整个项目的风格与语法。
• 如果未来需要与第三方库或旧代码互操作，ESM 中可以使用 createRequire，CommonJS 中可以使用动态 import，但当前目标是避免混用，建议严格遵循所选方案。

问题原因分析

• 主 goroutine 在 for v := range resCh 循环中阻塞，只有当 resCh 被关闭时该循环才会退出。
• resCh 的发送方是多个 worker，而当前代码中没有任何一处关闭 resCh。worker 在 jobCh 被读尽并关闭后退出，但 main 仍在等待 resCh 被关闭，从而导致所有 goroutine 最终都阻塞，触发 fatal error: all goroutines are asleep - deadlock。
• 注意：通道应该由“最后一个发送方”关闭，接收方不应该关闭通道，否则会引发 send on closed channel。

两种安全修复方案

方案 A：等待所有 worker 完成后，由单独的 goroutine 关闭 resCh（推荐） 原理：只有发送方（worker）知道何时不再发送，因此使用 WaitGroup 统计发送方数量，全部完成后再关闭 resCh，这样 main 的 range 能正常结束。

示例代码： package main

import ( "fmt" "sync" )

func worker(jobCh <-chan int, resCh chan<- int, wg *sync.WaitGroup) { defer wg.Done() for j := range jobCh { resCh <- j * 2 } }

func main() { jobCh := make(chan int, 5) resCh := make(chan int, 5)

var wg sync.WaitGroup
nWorkers := 2
nJobs := 5

// 启动 workers
wg.Add(nWorkers)
for i := 0; i < nWorkers; i++ {
    go worker(jobCh, resCh, &wg)
}

// 生产任务
for i := 1; i <= nJobs; i++ {
    jobCh <- i
}
close(jobCh) // 关闭任务通道，表示不再有新任务

// 关键点：等待所有 worker 完成后关闭 resCh
go func() {
    wg.Wait()
    close(resCh)
}()

// 消费结果直到 resCh 被关闭
for v := range resCh {
    fmt.Println(v)
}

}

要点：

• 只在所有发送者结束后关闭 resCh，避免 send on closed channel。
• main 不会死锁，因为 range resCh 在接收完所有值后会在 close(resCh) 时退出。

方案 B：按“已知结果数”读取固定次数，不依赖关闭 resCh 原理：如果结果个数可预知（等于任务数 nJobs），可以读取 nJobs 次即可，不必关闭 resCh；随后再等待 wg 保证 worker 都退出。

示例代码： package main

import ( "fmt" "sync" )

func worker(jobCh <-chan int, resCh chan<- int, wg *sync.WaitGroup) { defer wg.Done() for j := range jobCh { resCh <- j * 2 } }

func main() { jobCh := make(chan int, 5) resCh := make(chan int, 5)

var wg sync.WaitGroup
nWorkers := 2
nJobs := 5

wg.Add(nWorkers)
for i := 0; i < nWorkers; i++ {
    go worker(jobCh, resCh, &wg)
}

for i := 1; i <= nJobs; i++ {
    jobCh <- i
}
close(jobCh)

// 读取固定 nJobs 次
for i := 0; i < nJobs; i++ {
    v := <-resCh
    fmt.Println(v)
}

// 确保所有 worker 退出
wg.Wait()

}

要点：

• 无需关闭 resCh，但必须读取恰好 nJobs 次，否则会出现阻塞或丢数据。
• 适用于结果数量与任务数量一致且可预期的情况。

并发最佳实践与注意事项

• 关闭通道的原则：谁发送，谁关闭；接收方不要关闭通道。多发送方场景下，用 WaitGroup 协调，等所有发送方结束再统一关闭。
• 不要依赖缓冲区“碰巧不满”来避免阻塞；缓冲只用于削峰，不改变正确性。
• 防止 goroutine 泄漏：确保每个发送者/接收者都有退出路径（如关闭通道或读取固定次数）。
• 明确结果数量：如果结果数 = 任务数，按计数读取可减少一个关闭步骤；若不可预期或需要流式消费，使用“WaitGroup + 关闭结果通道”的模式。
• 结果顺序：多 worker 并发下结果顺序不确定，若需有序输出，携带任务序号并在接收端重排或用 slice 按索引写入。

采用上述任意一个方案，你的程序都会打印 5 个结果并正常退出，不再发生死锁。