oyps

我大致解决了这个问题，首先 concurrently 是基于 child_process.spawn 的，我测试发现，在 Windows 环境下，spawn 方法执行 tsx watch xxx.ts （ ts 文件导入了 mysql2 包）无法监听到 stdout 和 stderr 的任何输出，原因是 tsx watch 是基于类似 Scanner 实现的，也就是在每次 TS 文件刷新后，通过等待用户输入来使终端不结束，而 spawn 或者说 concurrently 默认情况不会将子进程（ tsx watch ）的输入输出进行 ignore ，所以只要在 spawn 调用时，将子进程的 stdio 数组中的第一项设置为 ignore 就可以解决该问题。

所以这算是谁的问题呢，我认为应该算是 tsx 的问题，tsx watch 处于等待文件更新状态时，终端看上去是出于阻塞状态的，但是此时直接输入字符串，按下回车，是会触发交互的（ vite 就不会，终端阻塞后，后续输入字符串，按下回车不会有反应）。

[卡住无输出] concurrently "tsx watch main.ts"

[正常输出] concurrently "bun --hot main.ts"


1. 为什么 bun --hot 正常，tsx watch 不正常，是 tsx 的问题？
2. 为什么 concurrently 加 --raw 正常，不加不正常，是 concurrently 还是 tsx 问题？
3. 为什么 mysql2 不正常，但是 mysql 却正常，是 mysql2 的问题？
4. 我尝试将 tsx watch 的输出转发到文件，然后用 Hex 查看，发现不管有没有 mysql2 ，输出内容都是一样的
5. 猜测：mysql2 包对程序的输出方式做了某种改变，这种改变，经过 tsx watch 输出后无法被 concurrently 等待到输出，而 bun --hot 则应该是同一了输出方式，而无视 mysql2 对终端输出方式的改变