JavaScript 执行设计
1. 重要通知：当前限制
1.1 功能状态
当前 execute_javascript 功能存在较多实现问题，暂不推荐使用。由于技术限制，直接执行 JavaScript 可能导致不可预期的行为，包括性能问题、安全风险和稳定性问题。
机制说明：
execute_javascript(window_id, script)调用后会立即返回一个请求 id（int32_t），脚本的执行结果并不在该函数的返回值中，而是通过javascript-result事件异步回传（事件event_data中包含对应的请求 id 与执行结果）。
1.2 推荐替代方案
强烈建议使用以下替代方案：
- 预载 JavaScript (preload_js)：在 WebView 初始化时注入预加载脚本，实现主进程与渲染进程通信
- IPC 通信：通过事件机制实现主进程与渲染进程交互
2. 设计建议：IPC 通信优先
2.1 核心建议
优先使用 IPC 通信实现主进程与渲染进程交互，避免直接执行 JavaScript 操作渲染进程页面。
2.2 IPC 通信 vs 直接执行 JavaScript
| 维度 | IPC 通信 | 直接执行 JavaScript |
|---|---|---|
| 安全性 | ✅ 明确接口，权限可控 | ❌ 注入风险，权限过大 |
| 性能 | ✅ 异步高效，事件驱动 | ❌ 开销大，可能阻塞渲染 |
| 可维护性 | ✅ 主进程与渲染进程分离，易测试 | ❌ 逻辑分散，难管理 |
| 调试 | ✅ 支持浏览器工具，日志完整 | ❌ 错误定位困难 |
2.3 适用场景
| 需求类型 | 推荐方案 |
|---|---|
| UI 更新 | IPC 事件 + 渲染进程处理 |
| 数据传递 | IPC 结构化数据 |
| 函数调用 | IPC 事件触发 |
| 状态同步 | IPC 双向事件 |
| 测试调试 | 直接执行 JS（例外） |
| 一次性操作 | 直接执行 JS（例外） |
2.4 最佳实践
- 优先设计 IPC 接口，明确主进程与渲染进程契约
- 仅在特殊场景使用
execute_javascript，脚本保持简单 - 避免在动态 JS 中包含复杂逻辑
- 严格验证输入输出，记录执行日志