composer不支持管理webassembly组件，它仅解析下载php依赖包，wasm文件无法被composer install处理，因wasm模块既不在packagist注册，也无法被php自动加载器加载；compose-multiplatform的wasm构建由kotlin编译器通过gradle完成，与composer完全无关。
Composer 不支持管理 WebAssembly 组件，也不参与跨平台 UI 框架（如 compose-multiplatform）的组件集成。
它只解析、下载和配置 PHP 依赖包，所有行为被严格限定在 PHP 生态边界内。Wasm 组件属于编译产物或前端运行时资源，与 composer.json 的依赖声明机制无任何语义或执行层面交集。
为什么 composer install 对 Wasm 文件完全无效
composer install 仅读取 composer.json 中的 require 字段，匹配 Packagist 或私有仓库中的 PHP 包（即含 autoload 配置、PHP 类文件的 zip/tar 归档）。Wasm 模块通常是：.wasm 二进制文件、index.html 入口、或由 Kotlin/ Rust 编译生成的 JS/Wasm 混合产物——这些既不注册在 Packagist，也无法被 Composer 的 autoloader 加载。
compose-multiplatform 的 Wasm 构建必须绕过 Composer
当你用 compose-multiplatform 开发 Web 应用时，Wasm 输出由 Kotlin 编译器（kotlin-wasm 后端）直接生成，路径类似：build/wasmJs/productionExecutable/kotlin/myapp.js 和 myapp.wasm。这个过程：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 由 Gradle 的
wasmJsDSL 触发，与composer命令零耦合 - 输出物需手动或通过构建脚本复制到 Web 服务器的静态资源目录（如
public/），而非vendor/ - 若 PHP 后端要调用该 Wasm 应用，只能通过 HTTP 请求（如
file_get_contents('http://localhost:8080/myapp.js')），不能 require 或 include
常见混淆点：名字带 “compose” 就以为能互通？
名字相似纯属巧合：Bot Framework Composer 是微软的低代码聊天机器人编辑器；compose-multiplatform 是 JetBrains 的 Kotlin UI 框架；而 Composer 是 PHP 的依赖管理工具。三者技术栈、设计目标、生命周期完全不同：
-
Composer运行在构建阶段，输出 PHP 类自动加载映射 -
compose-multiplatform的 Wasm 构建运行在 Gradle 环境，输出浏览器可执行字节码 - 二者共存于同一项目时，只是物理上并列（比如 PHP API + Kotlin Wasm 前端），不存在依赖注入或共享配置
.wasm 文件怎么放到 Nginx 的 /var/www/html 下，而不是幻想 composer require jetbrains/compose-wasm 能生效——后者根本不存在，Packagist 里搜不到，也永远不会支持。
