关于webview路径加载的bug反馈

这个问题大概率是你的代码里有调用其它子程序造成的。可以去除相关子程序调用试试。

结论

这个动作的白板问题基本可以排除"映射晚于导航"。动作定义（我通过 GetSharedActionByLink 接口拿到，修订 347）显示它确实用了 myserver|{serverPath} 映射和 HTML 内容模式，但 Quicker 侧代码是先映射后 NavigateToString，顺序正确。更关键的证据来自反馈帖（ViewTopic/41998）：

• 用户说的是每次开机后第一次启动空白，多启动几次就正常。映射文件在磁盘上不会因为开机消失，若真是映射失败，应当每次都失败。
• 作者给的"去掉全部功能代码、只留标题"的测试动作在用户机器上正常，说明 WebView2 本身能起来，问题在页面脚本链路。
• 用户截图里 DevTools 已列出 myserver/image 和 math.js 节点，说明这些资源被解析加载了。No resource with given URL found 是 DevTools 对 NavigateToString 产生的 about:blank 文档本身无法回读源码的常规提示，不是资源缺失报错。

页面实际的启动链路

页面 HTML 约 42KB，在文档解析阶段依次做四件事，任何一环卡住都表现为白板：

1. 立即调用 $quickerSp('cal_check') 和 $quickerSp('turnOffMsgWindow')，两者都指向作者的服务器共享子程序。
2. init() 动态插入 <script src="https://myserver/math.js">，等 onload。
3. onload 后 await $quickerSp('getContent')，从子程序取回主 JS 再注入。主 JS 内联在动作变量里，不依赖映射目录。
4. 整个 init() 外层是 try { } catch {} 空吞异常，失败无任何提示。

映射目录只承载 math.js 和两个 svg 图标。未配置 defaultBgColor 时 WebView 底色为透明，透出 WPF 窗口的浅色底，所以"白板"本身不能证明 WebView 没起来。

最可能的成因（按可能性排序）

1. $quickerSp 回调在冷启动时挂起。 桥接层（QuickerWebViewBridge.cs:302-346）在线程池线程执行子程序，完成后用 IDispatch 从后台线程回调 JS，这需要 marshal 回 UI 线程。该动作把打开窗口的步骤放在 useMultiThread=1 的并行组里，同时另一线程跑远程子程序 readyWebview（大概率再开一个预热窗口）并反复做阻塞式 RunOnUiThread(true)。开机首次运行时 WebView2 运行时冷启动最慢，UI 线程争用最严重，await $quickerSp('getContent') 不 resolve，主 JS 永远注不进去。这与"首次空白、之后正常"最吻合。此条为推断。
2. 注入的桥接脚本自身抛错导致 $quickerSp 未定义。 WebView2Window.xaml.cs:592 用 Promise.resolve(hostObjects.v) 对异步宿主代理做 .then 探测，文件头注释已承认 .NET 10 下访问不存在的成员会抛 0x80070057。IIFE 一旦抛错，后面第 596 行的 window.$quickerSp 赋值不再执行，页面首行就 ReferenceError。此条为推断，但机制是代码事实。
3. CoreWebView2 == null 早退路径（WebView2Window.xaml.cs:707-712）只弹提示、不关窗、不导航，OpenUrlAndWaitClose 随后无限死等。这是 Quicker 侧确定的缺陷，但用户没提到弹窗，可能性排第三。
4. 上一轮提到的映射解析缺陷（host 未 Trim、路径未归一化、窗口复用不重设映射）在这个动作里不触发：映射值由子程序生成、无空格，且 CheckWindowState 分支下窗口已存在时走 SendMessage 而非重开。