Vite mergeConfig 报 Property description must be an object，检查 ws:false

Vite 还没监听端口，就抛出 TypeError: Property description must be an object: undefined。若配置经过 mergeConfig 或多个插件合并，查看是否同时存在 server.ws: false 与两份 server.hmr 对象。

Vite 8.3.0 的明确触发形状是：

import { mergeConfig } from 'vite';

const base = { server: { ws: false, hmr: { host: 'localhost' } } };
const override = { server: { hmr: { port: 5173 } } };
const config = mergeConfig(base, override);

这个例子用于认出合并结构，不需要浏览器或反向代理参与。旧实现遇到 ws: false 会跳过 HMR 到 WebSocket 的兼容访问器安装，后面的合并却仍尝试复制那些属性描述符；描述符不存在，Object.defineProperty 因而收到 undefined。

不必为了启动而重新开启 WebSocket

先保留实际版本、完整配置和插件返回的 config，找出哪一步写入 ws: false，哪一步继续追加 hmr 连接选项。只看最终配置文件可能不够，框架插件也会返回需要合并的片段。

如果业务有意关闭 WebSocket，不应改成 ws: true 只为避开异常。关闭状态可能与测试、嵌入或开发服务接入方式有关；重新开启会改变服务行为。短期需整理配置时，可以让关闭 WebSocket 的路径不再携带无效的连接覆盖，但应核对 HMR 的其他选项和插件用途，不能粗暴删除所有 hmr 设置。

8.3.4 会检查描述符是否存在

Vite 8.3.4 的正式合并代码在复制描述符前增加了存在性判断。框架与插件允许时，在原依赖管理流程中采用包含修正的兼容正式版，并检查锁文件实际解析到的 Vite。

保留上面的合并条件做回归：合并不再抛异常，结果仍为 server.ws === false，没有因为更新意外启用连接。项目本来就需要 WebSocket 的另一个环境，也应检查实际 host、port 和协议没有被变更。

该问题与复用默认对象后“第二次合并继承第一次端口”是两条不同表现。后者涉及默认对象被访问器修改；本题是在首次合并中复制不存在的描述符。不要只用跨两次合并的脚本替代这里 ws: false 的检查。

最后从原项目入口启动服务，确认配置阶段通过，再检查原来需要的页面与开发交互。启动恢复不等于业务构建通过，仍要执行项目正常的构建验证。回退时恢复原配置和锁文件的配套组合，避免新旧插件各使用一份不兼容的 Vite。