“速度慢、准确率高”的谷歌翻译在翻译特定文本时会报错

[lmk123]

基本信息

划词翻译版本：v10.4.1
浏览器版本：chrome 119
操作系统：macos

重现问题的步骤

分别翻译下面几段话：

Jest and jsdom seem to default to the first approach. jsdom [won't use implementations](https://www.github.com/jsdom/jsdom/issues/1724#issuecomment-285971986) if they're not W3C-spec-compliant, and Jest uses the VM API (I think) to exclude Node.js globals (so code under test won't mistakenly reference them), and Jest decides to emulate the browser as closely as possible when using jsdom, including honoring the "browser" export conditions of Node modules. (And, since Jest's jsdom environment doesn't expose Node.js globals, some packages need to have their "browser" export conditions honored, so they'll reference browser globals rather than Node.)

Vitest takes the second approach (e.g., it exposes Buffer because ["TODO a lot of dependencies use it"](https://github.com/vitest-dev/vitest/blob/3397fdc45cc0f57df4f7afe08e472a9c5ff360b9/packages/vitest/src/integrations/env/jsdom.ts#L69)) - but that means I can have production browser-side code that mistakenly references Buffer and passes tests and fails at runtime. MSW 2 picks the second approach (for [reasons that you explain in depth](https://mswjs.io/blog/introducing-msw-2.0#the-essence)), and I'm certain those are the correct tradeoffs for MSW - but now I have test failures because new FormData(form) no longer works. (This is not a complaint and not your problem.)

 (~170MB macOS, ~282MB Linux, ~280MB Windows)

预期行为

都能正常获取翻译结果

实际行为

均报错“10 秒无结果”

补充信息