不同浏览器平台上的 WebAssembly 行为
说明 WebAssembly 的可移植性、合理的平台差异，以及如何跨浏览器版本测试模块而不混淆正确性和速度。
WebAssembly 为浏览器提供可移植的编译模块格式，但可移植不代表所有浏览器与宿主具有相同功能、资源或性能。实际合同更具体：模块可以依赖其受支持环境所提供的指令和宿主服务。比较版本前，应先记录这些需求。这样讨论的就是应用任务是否兼容，而不是假设格式消除了平台差异。WebAssembly Core 规范定义可移植指令的行为，周边网页环境仍由浏览器提供。
模块包含类型化指令，并可以声明内存以及连接宿主的导入项。规范定义受支持核心指令的行为，网页和浏览器则提供输入、存储和显示等服务。只依赖常见功能集和受控输入的模块，比依赖可选功能或宿主专有服务的模块更易迁移。明确这条边界，有助于区分哪些行为随模块移动，哪些必须在嵌入模块的应用中重新检查。
功能可用性属于这份合同。即使源程序看似未变，编译器也可能输出较旧运行时不支持的指令。不同浏览器的支持进度并不一致，因此文件格式本身不保证所有指令都存在。应在构建过程中明确最低功能集。若依赖可选能力，可提供面向更广基线的构建版本或应用回退，并测试网页如何在它们之间选择。
导入项把模块连接到 WebAssembly 核心未定义的行为。网页可以提供数据访问或应用服务函数，而这些函数遵循各自规则。Core 规范的导入规则定义了导入项如何声明，但导入项匹配并不保证不同浏览器提供相同的宿主能力。应限制导入接口，并记录允许的输入与输出。
应区分各个阶段：validate()检查模块字节，compile()生成 WebAssembly.Module，而 instantiate()解析导入项并创建实例。实例化还要求模块有效（Core 规范）。应将各阶段失败作为不同的应用状态处理，并保留源输入。可选模块应等到相关任务被请求时再加载；加载完成不能证明用户系统的任何情况。
模块产物也应视为有版本的接口。导出函数和导入服务构成它与网页之间的合同，就像网络请求或已存储记录一样。自定义 section可以包含调试信息或第三方数据，但它属于可选元数据，WebAssembly 语义会忽略它；它不能替代应用版本管理或发布决策。页面接口说明仍应属于应用合同。编译器升级可能改变二进制文件而不改变合同，因此比较应用行为，不必要求字节相同。
合理结果差异的来源
宿主提供资源与导入函数。因此，文件访问、时钟、网络、存储和应用服务分别受各自合同约束，资源上限和调度也可能不同。执行速度不是跨设备常量，性能变化不应被误认为模块语义发生变化。关注正确性时，应按模块与应用合同比较结果，而不是与另一台系统上记录的耗时比较。
一些数值运算有严格定义，另一些则允许实现保留一定余地。WebAssembly 值转换为 JavaScript 值、应用解析或序列化数据时，也可能影响结果。若工作流依赖特定数值，应确认涉及的运算与表示方式。不要假设所有运行时在每个细节上都返回完全相同的值；修改比较规则前，应核对相关标准与领域要求。
模块还受可用资源影响。内存分配、表增长、栈使用和输入规模都会影响任务能否完成。浏览器可能为稳定性限制资源，这些限制并不描述宿主的物理内存。分配失败应视为资源条件，而不是设备身份。应用可限制工作规模、保留用户输入，并在任务无法继续时提供其他路径。
可选功能也可能与部署环境有关。例如，模块需要的运行条件可能被网页安全策略或 worker 设置限制。于是，同一路径在开发者本地测试页可行，在产品页面却可能被拒绝。应测试产品实际部署的上下文，包括页面策略与 worker 用法，并记录相关要求。这比收集运行时的无关属性更有用。
并发假设也应纳入部署合同。使用共享内存或 worker 协调的模块，可能需要比单线程模块更严格的页面条件。如果产品支持两种路径，应确认选择逻辑正确，而且两种路径遵循相同的用户数据合同。单线程路径响应可能不同，但仍可为有限任务给出有效结果。不能仅因可选的并发路径不可用就关闭整个功能。应说明受支持的上下文，并在与主路径相同的部署策略下测试回退。
应区分三个边界引起的差异：编译后的模块、浏览器的 WebAssembly 实现，以及应用提供的宿主服务。若模块产物变化，新的编译目标或源码修订可能解释结果。若产物不变而导入服务变化，应检查页面集成。若两者均固定而行为随浏览器版本不同，运行时才是相关比较对象。此方法不预设原因，而是按顺序检查证据，避免把所有跨平台结果都当作浏览器缺陷。
隐私与可重现性
WebAssembly 是执行格式，不是隐私边界。模块可以在本地处理信息，但宿主导入项和周边应用决定输入或结果之后是否会被保存或传输。应审查从数据收集、模块内存、返回值、日志、导出到删除的完整流程。计算发生在浏览器中，并不能证明整个工作流都留在本地或应用没有保留数据。
传给模块的数据应限于任务所需。编译后的模块会交付给客户端，应视为可检查的应用代码，而不是隐藏凭据或私有记录的地方。敏感服务操作应有适当授权，宿主也只应开放用户任务所需的服务。用户取消任务或关闭视图时，应尽可能停止工作并释放仍引用输入数据的对象。
为取得可重现结果，应固定模块产物、编译设置、导入项、输入和所需浏览器功能。若模块读取时钟、接收宿主提供的随机数据或查询可变存储，那么多次运行结果不同是合理的。这些输入属于应用合同。需要可重现时，测试应控制它们；如果用户工作流依赖其变化，则要在预期中明确说明。
能力信息可帮助应用选择兼容路径，但不应默认成为长期身份记录。若需要支持诊断，应与用户报告的问题关联，仅保留复现问题所需的版本和结果，并在支持目的结束后删除。避免收集无关计时或资源观察。这样兼容性处理针对可复现任务，而不是给运行环境分类。
模块中的依赖也需要常规的隐私与维护检查。模块可能包含处理输入或格式化输出的库；编译不会改变这些库的许可和更新历史。应保留交付产物所用源码依赖和编译配置的记录，以便维护者更新库时判断变化所在，无需把二进制视为不透明，也不必收集用户设备详情。如果依赖在应用层新增网络访问或持久化行为，应明确审查。编译不会免除理解所交付软件数据路径的责任。
应谨慎向用户说明本地执行。浏览器中的模块可能让中间计算留在设备上，但应用仍可能在执行前发送输入，或在完成后发送结果。网页也可能从远程来源加载模块和模型。应检查模块周围的网络请求与存储行为，而不能从执行格式推断数据处理方式。应用提供离线路径时，应在断网情况下测试并说明仍可使用哪些功能。对外说明应符合观察到的产品行为，不应变成 WebAssembly 的一般承诺。
模块兼容性
记录模块要求的最低 WebAssembly 功能集以及网页依赖的宿主导入项，并将这些要求与模块修订一起维护，避免后续构建在不知情时抬高浏览器基线。对于可选功能，应准备另一构建版本或页面级回退。兼容性说明应指出已测试的用户流程，而非暗示格式本身保证所有浏览器都支持。
测试模块周边的完整路径：加载、实例化、宿主导入、代表性输入、输出解释和预期失败。成功实例化并不能证明用户任务得到可接受结果。任务失败也可能来自输入转换或宿主集成，而非缺少 WebAssembly 指令。测试套件应区分这些情况，让维护者针对正确边界处理。
WebAssembly 与 JavaScript 交换数值时，应定义其表示方式和范围。明确接口使用整数、浮点值、字节缓冲区还是结构化记录，并测试两端的转换。序列化和存储还会带来各自的表示规则。精确十进制记账应选择合适表示，并在接口处定义舍入，而不是依赖某个运行时的偶然行为。
回退行为也是兼容性的一部分。所需功能不可用时，应用可以选用面向更广基线的模块、功能受限的替代方案，或解释当前无法执行。应使用相同用户输入测试回退，并确认它不会丢弃未完成的工作。若输出精度或工作规模不同，应清楚说明取舍。源代码里有回退，但部署页面无法选择它，对用户没有帮助。
页面与模块的合同还应说明内存和所有权。调用方需要知道缓冲区是被复制、仅在有限操作期间借用，还是按接口约定保留供后续使用。应明确所有权，避免页面在模块任务仍依赖数据时复用或丢弃它。完成或取消后，释放应用引用并恢复到可开始下一任务的状态。测试除单次成功外还应覆盖重复使用，因为生命周期问题常在多次操作后才出现。
模块的公开接口应保持稳定，以便调用方正确处理错误。定义哪些失败可作为普通结果返回，哪些表示模块无法继续。页面应将结果映射为可恢复的用户状态，而不是留下只更新一半的记录或禁用的控件。不要依赖特定运行时的错误消息文本作为应用合同。使用已记录的返回结构和应用自己的状态处理，并在每种支持的浏览器中测试。这样模块实现可演进，用户恢复流程也不依赖偶然措辞。
比较浏览器版本
比较候选浏览器版本时，应固定模块产物、应用修订、导入项、输入和部署环境。记录版本以及每项必要用户流程的功能结果。如果模块或测试套件也发生变化，应保留旧产物和预期结果，直到差异得到解释。一次改变多个变量，很难分辨结果来自浏览器、编译器、应用还是测试。
正确性与性能证据要分开。模块执行较慢仍可能符合功能合同，而一次快速运行也不能证明输出正确。如果响应速度影响用户，应测量有代表性的应用任务，并说明工作负载和环境。不要把耗时重用为浏览器或设备标签。调度、后台活动、电源状态和运行时变化都会影响时间。
测试结果变化时，将用例缩减为小输入并核对对应规范要求。标准严格定义的行为与允许近似的运算需要不同解释。归因于浏览器版本前，还应检查应用转换、导入项、编译设置和宿主数据。精简复现能把兼容性问题限定在具体范围内，不需要用户数据或无关属性清单。
编译器升级和模块交付也应采用同样原则。浏览器不变时，编译器仍可能输出不同功能集或二进制产物。若应用交付多个模块版本，应测试选择逻辑与缓存，确认部署后每种受支持环境都能拿到预期文件。产品需求变化时重新评估支持的浏览器范围。这种发布方法补充了浏览器版本验证，并与浏览器计时信号保持不同范围。
模块升级影响应用任务时，应明确任务、输入或输出合同的变化，以及已测试的浏览器范围。如果用户需要刷新离线缓存或重试中断任务，应在应用流程中提供清楚提示。维护者需要产物和构建来源，用户需要知道自己的流程和已存数据是否受影响。支持范围变化时更新兼容记录；模块开始依赖新功能时也要重新评估，不要承诺所有宿主上速度或行为完全一致。
扩大支持范围前，明确应用承诺维护哪些浏览器版本与模块功能。既要测试最早的受支持基线，也要测试候选版本，并将结果与模块及应用修订一起保留。若产品有可比较结果并能在问题出现时恢复，可先对内部或有限用户推出。模块变化影响用户依赖的数据时，应提供清楚的迁移或重试路径。只有支持政策和部署缓存行为都允许后，才移除旧模块版本。这样发布维护遵循明确兼容承诺，而不是开发团队手头最新的浏览器。
