ArkTS 并发：TaskPool 和 Worker，选错的代价是主线程卡死

ArkTS 是单线程模型，跑重活必须开并发。TaskPool 和 Worker 都能用，但适用场景差别很大，选错了反而更难维护。

TaskPool 适合短任务：解码图片、算哈希、解析大 JSON。用 @Concurrent 装饰函数，taskpool.execute 提交，返回 Promise。它的线程池由系统管理，任务结束线程回收，不用自己管生命周期，代码量和同步写法几乎一样。

Worker 适合长任务或者需要保持状态的场景：比如维持一个 WebSocket 长连接、跑一个持续的定时采集。它需要单独的文件、手动 postMessage 通信、手动 terminate，成本更高但控制力更强。

有一条限制必须记住：@Concurrent 函数不能访问闭包，也不能引用外层变量，参数和返回值必须可序列化。想在任务里用一个外部配置对象，只能把它作为参数传进去，否则编译能过、运行时拿到 undefined。

选型建议：先问「这个任务要跑多久」。100ms 以内其实不必开线程，拆分得当的同步代码往往比线程调度更快；几百毫秒以上的计算才值得 TaskPool，超过几秒还要持续那就上 Worker。