Compose Multiplatform 中 WASM 加载图片资源的 CORS 问题解析

在 Compose Multiplatform 项目开发中，当使用 WebAssembly(WASM) 技术栈时，开发者可能会遇到一个棘手的跨域资源共享(CORS)问题。这个问题特别表现在尝试加载远程图片资源时，与常规网页中的图片加载行为存在显著差异。

问题现象

在传统网页开发中，当使用 <img> 标签加载远程图片时，浏览器会自动设置特定的请求头：

Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: image

这种配置允许浏览器即使在没有 CORS 允许来源头的情况下也能成功加载图片资源。然而，在 Compose Multiplatform 的 WASM 环境中，当通过代码(如使用 Coil 库或手动请求)加载图片时，请求并非来自标准的 <img> 标签，导致浏览器设置了不同的请求头：

Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty

这种变化使得请求必须遵守严格的 CORS 策略，如果服务器未正确配置 CORS 响应头，请求就会失败。

技术背景

CORS 是现代浏览器实施的一种安全机制，用于控制跨域请求。在 WASM 环境中，由于请求是通过 JavaScript/WebAssembly 代码发起的，而非传统的 HTML 元素，浏览器会应用更严格的安全策略。

浏览器根据请求来源自动设置 Sec-Fetch-* 头：

• no-cors 模式允许简单请求绕过严格的 CORS 检查
• cors 模式要求服务器明确允许跨域请求
• Sec-Fetch-Dest 指示请求的目标类型，影响浏览器的安全决策

解决方案探讨

目前可行的解决方案包括：

1. 服务器端配置：确保图片服务器正确设置 CORS 响应头，如 Access-Control-Allow-Origin

2. 中转服务：通过设置反向代理(如 Nginx)来处理资源请求

3. 替代加载方式：考虑将图片资源内联为 data URL 或转换为 base64 编码

4. WASM 请求模拟：探索是否可以通过 WASM 代码模拟浏览器原生 <img> 标签的请求行为

安全考量

从安全角度来看，浏览器限制 WASM 代码直接加载图片资源有其合理性。这种限制防止了恶意代码通过 WASM 获取任意二进制数据。理想的解决方案应该既能满足开发需求，又不破坏 Web 安全模型。

未来展望

Compose Multiplatform 团队可能需要考虑以下方向：

• 提供声明式 API 来明确指定资源类型
• 实现底层请求机制的优化
• 与浏览器厂商合作探讨 WASM 环境下更灵活的 CORS 策略

开发者在使用 Compose Multiplatform 的 WASM 目标时，应当充分了解这一限制，并在项目规划阶段就考虑好图片资源的加载策略。