Vite 深路径导入 Svelte 组件，依赖扫描失败

导入 svelte-lib/Banner.svelte 后，开发服务器报依赖扫描失败，错误是 [UNRESOLVED_IMPORT]，在 virtual-module: 中找不到组件内部的 ./Icon.svelte。文件实际存在，换成包入口导入却能正常扫描时，应检查深路径组件是否被误当成应用源码继续爬取。

Vite 8.3.3 有这一明确表现，8.2.1 也出现相同错误。正式 8.3.4 已修正自定义扩展的深路径依赖扫描，8.3.5 保留该处理。条件是组件真实解析到 node_modules，且插件通过 optimizeDeps.extensions 让这类扩展可被优化。

深路径绕开了依赖登记

组件入口例如：

import Banner from 'svelte-lib/Banner.svelte';

库内 Banner 再相对导入 Icon。旧扫描器在处理 html 类扩展时，本应把可优化的 node_modules 文件交给后面的裸包导入分支，记录为依赖并停止继续爬取。

但返回 undefined 在统一 resolveId 函数中直接结束了处理，不再像此前多个独立回调那样继续落到下一个回调。随后组件脚本被装进虚拟模块，内部相对路径在这条错误路径中解析失败，整次扫描被跳过。

页面首次加载时才陆续发现依赖，还可能触发 optimized dependencies changed. reloading，旧依赖地址随之报 504。504 是后续时序表现，不能只靠反复刷新处理最初的扫描错误。

采用包含扫描修正的版本

在框架和 Svelte 插件支持范围内采用 Vite 8.3.4 或包含同样处理的兼容版本，保留原扩展配置重新启动开发环境。正式修正让可优化的 node_modules 组件继续进入依赖登记分支，而不是把整个项目改为不扫描。

暂不能更新，且库确实从主入口导出同一个组件时，可以改用它提供的入口，例如：

import { Banner } from 'svelte-lib';

这里要求库的 exports 和入口实际提供 Banner，不能凭文件名猜命名导出。入口还可能改变副作用与导入范围，应核对组件实现和现有行为。不要删除扩展配置或直接改 node_modules 中的扫描器，把一次本地补丁当成可重复交付的修复。

保留真实安装位置验收

文件夹依赖可能被链接到 node_modules 之外，不会经过相同分支；用它替代实际安装包后错误消失，不能证明已覆盖这次故障。验收应使用项目原来的包安装方式和深路径入口，确认预扫描不再跳过，依赖在首次打开前已被发现，页面和组件内部导入正常。

如果错误其实是包 exports 禁止子路径、文件大小写不一致或组件确实缺失，应按那个解析错误处理。扫描修正不会生成不存在的 Icon，也不等于生产构建自动获得相同结论。