Emscripten 编译器设置¶
以下是可以通过命令行上的 -s 传递给 emscripten 的所有设置列表。例如 -sASSERTIONS 或 -sASSERTIONS=0。有关更多详细信息，请参阅 emcc 文档。
除非另有说明，否则这些设置仅在链接时应用，对编译没有影响。
ASSERTIONS¶
是否应该添加运行时断言。这会影响 JS 和系统库的构建方式。ASSERTIONS == 2 会提供更多运行时检查，这些检查可能非常慢。这包括内部 dlmalloc 断言，例如。
默认值：1
STACK_OVERFLOW_CHECK¶
选择要为生成的代码发出哪种堆栈溢出检查：使用 ASSERTIONS=1 构建会导致 STACK_OVERFLOW_CHECK 默认值为 1。由于 ASSERTIONS=1 是 -O0 的默认值，而 -O0 本身是默认优化级别，这意味着在没有其他设置的情况下，此设置也默认设置为 1。
0：不会检查堆栈溢出。
1：在堆栈顶部添加一个安全 cookie，该 cookie 在每次滴答结束时和退出时进行检查（实际上几乎没有性能开销）
2：与上述相同，但还会运行一个 binaryen 过程，该过程在所有堆栈指针赋值中添加一个检查。有一点性能成本。
默认值：0
CHECK_NULL_WRITES¶
当启用 STACK_OVERFLOW_CHECK 时，我们还会检查对地址零的写入。这可以帮助检测空指针的使用。如果您想跳过此额外的检查（例如，如果您希望从地址零读取始终返回零），您可以在此处禁用它。当禁用 STACK_OVERFLOW_CHECK 时，此设置无效。
默认值：true
VERBOSE¶
当设置为 1 时，将在编译期间生成更详细的输出。[general]
默认值：false
INVOKE_RUN¶
是否要运行 main() 函数。如果您将生成的代码嵌入到自己的代码中，并且将在正确的时间自己调用 main()（您可以使用 Module.callMain() 来执行此操作，并带有一个可选的命令行参数），则禁用它。
默认值：true
EXIT_RUNTIME¶
如果为 0，则在 main() 完成后不会退出运行时（允许代码在之后运行，例如来自浏览器主事件循环）。atexit() 也不会执行，我们可以避免包含运行时关闭的代码，例如刷新 stdio 流。如果您确实希望在退出时执行 atexit() 或刷新 stdio 流，则将其设置为 1。此设置在 STANDALONE_WASM 模式下自动控制
对于命令（具有主函数），这始终为 1
对于反应堆（没有主函数），这始终为 0
默认值：false
STACK_SIZE¶
总堆栈大小。无法扩大堆栈，因此该值必须足够大以满足程序的要求。如果断言打开，我们将在不超过此值的情况下断言，否则，它会静默失败。
默认值：64*1024
MALLOC¶
使用哪个 malloc()/free()，可以选择以下内容：
dlmalloc - 一个功能强大的通用 malloc
emmalloc - 为 emscripten 设计的简单而紧凑的 malloc
emmalloc-debug - 使用 emmalloc 并添加额外的断言检查
emmalloc-memvalidate - 使用 emmalloc 进行断言+堆一致性检查。
emmalloc-verbose - 使用 emmalloc 进行断言+详细日志记录。
emmalloc-memvalidate-verbose - 使用 emmalloc 进行断言+堆一致性检查+详细日志记录。
mimalloc - 一个功能强大的多线程分配器。这建议在具有 malloc() 争用的大型应用程序中使用，但它更大且使用更多内存。
none - 不提供 malloc() 实现，但您必须自己实现 malloc() 和 free()。
dlmalloc 是分割内存和其他特殊模式所必需的，并且将在这些情况下自动使用。一般来说，如果您不需要这些特殊模式之一，并且如果您没有分配太多的小对象，则应该使用 emmalloc，因为它更小。否则，如果您确实分配了许多小对象，dlmalloc 通常值得额外的大小。如果您想要它进行的额外安全检查（例如，注意到其内部数据结构中的元数据损坏，而 emmalloc 不会这样做），dlmalloc 也是一个不错的选择。
默认值：“dlmalloc”
ABORTING_MALLOC¶
如果为 1，则当 malloc 失败时，我们中止。这不是标准行为，但对网络来说很有意义，因为我们有一段固定数量的内存，必须在前面全部分配，因此 (a) 失败的 malloc 比其他平台上更可能，并且 (b) 人们需要一种方法来找出该初始分配 (INITIAL_MEMORY) 必须有多大。如果您将其设置为 0，那么您将获得标准 malloc 行为，即在失败时返回 NULL (0)。
设置 ALLOW_MEMORY_GROWTH 会关闭它，因为在这种模式下，我们默认行为是在失败时尝试增长并从 malloc 返回 0，就像标准系统一样。但是，您仍然可以设置此标志以覆盖它。这基本上是向后兼容的更改。以前，当增长打开时，此选项被忽略。当前的行为是增长默认关闭它，因此对于从未指定标志的用户来说，没有任何变化。但是，如果您确实指定了它，它现在将起作用，而以前它没有。如果您不想要这样，只需在链接时停止传递它。
请注意，此设置不会影响 C++ 中 operator new 的行为。如果禁用异常，此函数将在分配失败时始终中止。如果您希望 new 在失败时返回 0，请将其与 std::nothrow 一起使用。
默认值：true
INITIAL_HEAP¶
程序可用的初始堆内存量。这是通过 sbrk、malloc 和 new 可用于动态分配的内存区域。
与 INITIAL_MEMORY 不同，此设置允许程序内存的静态区域和动态区域独立增长。在大多数情况下，我们建议使用此设置而不是 INITIAL_MEMORY。但是，此设置不适用于导入的内存（例如，当使用动态链接时）。
默认值：16777216
INITIAL_MEMORY¶
要使用的初始内存量。使用超过此内存量的内存会导致我们扩展堆，这对于类型化数组来说可能很昂贵：在这种情况下，我们需要将旧堆复制到新堆中。如果设置了 ALLOW_MEMORY_GROWTH，则此初始内存量可以在以后增加；如果没有，那么它就是最终的总内存量。
默认情况下，此值是根据 INITIAL_HEAP、STACK_SIZE 以及输入模块中静态数据的尺寸计算得出的。
（此选项以前称为 TOTAL_MEMORY。）
默认值：-1
MAXIMUM_MEMORY¶
设置 wasm 模块中内存的最大尺寸（以字节为单位）。这仅在设置 ALLOW_MEMORY_GROWTH 时才相关，因为如果没有增长，INITIAL_MEMORY 的大小无论如何都是最终内存的大小。
请注意，这里的默认值为 2GB，这意味着默认情况下，如果您启用内存增长，那么我们可以增长到 2GB，但不会更高。2GB 是一个自然的限制，原因有以下几个
如果最大堆大小超过 2GB，则指针必须在 JavaScript 中无符号，这会增加代码大小。我们不希望内存增长构建更大，除非有人明确选择加入到 >2GB+ 堆中。
历史上，没有 VM 支持超过 2GB+，直到最近（2020 年 3 月）才开始出现支持。由于支持有限，对于人们来说，选择加入到 >2GB+ 堆中比获得可能不适用于所有 VM 的构建更安全。
要使用超过 2GB，请将其设置为更高的值，例如 4GB。
（此选项以前称为 WASM_MEM_MAX 和 BINARYEN_MEM_MAX。）
默认值：2147483648
ALLOW_MEMORY_GROWTH¶
如果为 false，如果我们尝试分配超过我们所能分配的内存（INITIAL_MEMORY），我们就会中止并报错。如果为 true，我们将在运行时无缝动态地增长内存数组。有关 chrome 中内存增长性能的信息，请参见 https://code.google.com/p/v8/issues/detail?id=3907。请注意，增长内存意味着我们替换 JS 类型化数组视图，因为一旦创建，它们就无法调整大小。（在 wasm 中，我们可以增长 Memory，但仍然需要为 JS 创建新的视图。）在该选项上设置此选项将禁用 ABORTING_MALLOC，换句话说，ALLOW_MEMORY_GROWTH 使完全标准的行为生效，即 malloc 在失败时返回 0，并且能够根据需要从系统中分配更多内存。
默认值：false
MEMORY_GROWTH_GEOMETRIC_STEP¶
如果 ALLOW_MEMORY_GROWTH 为真，此变量指定堆在调整大小时的几何增长率。将 MEMORY_GROWTH_GEOMETRIC_STEP=0 设置为完全禁用堆的增长，或例如将 MEMORY_GROWTH_GEOMETRIC_STEP=1.0 设置为在每次增长步骤中将堆加倍 (+100%)。此值越大，WebAssembly 堆预留的内存越多，以减少来自内存调整的性能问题，此值越小，节省的内存越多，但在堆增长时会造成更多卡顿。（经过测试，大约为 ~20 毫秒）
默认值：0.20
MEMORY_GROWTH_GEOMETRIC_CAP¶
指定最大几何增长大小的限制，以字节为单位。使用此值限制几何增长，使其不超过特定速率。传递 MEMORY_GROWTH_GEOMETRIC_CAP=0 禁用限制，允许无限大小增长。
默认值：96*1024*1024
MEMORY_GROWTH_LINEAR_STEP¶
如果 ALLOW_MEMORY_GROWTH 为真且 MEMORY_GROWTH_LINEAR_STEP == -1，则使用几何内存增长（上面的变量）。将 MEMORY_GROWTH_LINEAR_STEP 设置为 WASM 页面大小（64KB）的倍数，例如 16MB，以使用恒定增长步长替换几何增长率。当使用 MEMORY_GROWTH_LINEAR_STEP 时，变量 MEMORY_GROWTH_GEOMETRIC_STEP 和 MEMORY_GROWTH_GEOMETRIC_CAP 将被忽略。
默认值：-1
MEMORY64¶
要编译的“体系结构”。0 表示默认的 wasm32，1 表示完整的端到端 wasm64 模式，2 表示 clang/lld 的 wasm64，但在 Binaryen 中降低到 wasm32（这样它可以在 wasm32 引擎上运行，同时在内部使用 i64 指针）。假定 WASM_BIGINT。
注意
适用于链接和编译期间
注意
这是一个实验性设置
默认值：0
INITIAL_TABLE¶
当使用 MAIN_MODULE 或 SIDE_MODULE 时设置表的初始大小（而不是其他情况）。通常，Emscripten 可以在链接时确定表的大小，但在 SPLIT_MODULE 模式下，wasm-split 通常需要扩展表，因此烘焙到 JS 中的表的尺寸对于已检测构建来说太小了，在模块被拆分后。这是一个技巧，允许用户指定一个足够大的表大小，该大小可以在两种构建之间保持一致。此设置可能随时被移除，并且不应使用，除非与 SPLIT_MODULE 和动态链接一起使用。
默认值：-1
ALLOW_TABLE_GROWTH¶
如果为真，则允许在运行时将更多函数添加到表中。动态链接需要此功能，并且在该模式下自动设置。
默认值：false
GLOBAL_BASE¶
全局数据开始的地方；静态内存的开始。GLOBAL_BASE 为 1024 或更高，对于优化加载/存储偏移量很有用，因为它启用了 –low-memory-unused 传递。
默认值：1024
TABLE_BASE¶
分配表槽位（函数地址）的位置。这必须至少为 1，以预留空指针的零槽位。
默认值：1
USE_CLOSURE_COMPILER¶
是否在该输出上运行闭包编译
默认值：false
CLOSURE_WARNINGS¶
已弃用：改用标准警告标志。例如 -Wclosure，-Wno-closure，-Werror=closure。选项：'quiet'、'warn'、'error'。如果设置为 'warn'，Closure 警告将打印到控制台。如果设置为 'error'，Closure 警告将被视为错误，类似于 -Werror 编译器标志。
注意
此设置已弃用
默认值：'quiet'
IGNORE_CLOSURE_COMPILER_ERRORS¶
忽略 Closure 警告和错误（例如重复定义）
默认值：false
DECLARE_ASM_MODULE_EXPORTS¶
如果设置为 1，每个 wasm 模块导出都将使用 JavaScript “var” 定义单独声明。这是简单且推荐的方法。但是，这确实会增加代码大小（尤其是在你有许多此类导出时），可以通过将此设置为 0 以不安全的方式避免。在这种情况下，不会为每个导出创建“var”，而是使用循环（无论你有多少个导出，都是固定的小代码大小）将接收到的所有导出写入全局范围。这样做很危险，因为对全局范围的这种修改可能会混淆外部 JS 缩小工具，并且如果代码所在的范围不是全局范围，也会出现问题（例如，如果你手动将它们封装在一个函数范围内）。
默认值：true
INLINING_LIMIT¶
如果设置为 1，则阻止内联。如果为 0，我们将在 LLVM 中正常内联。这不会影响 Binaryen 中的内联策略。
注意
仅适用于编译期间
默认值：false
SUPPORT_BIG_ENDIAN¶
如果设置为 1，执行 acorn 传递，该传递将每个 HEAP 访问转换为使用 DataView 强制 HEAP 缓冲区的 LE 字节顺序的函数调用；这使生成的 JavaScript 可以在 BE 和 LE 机器上运行。（如果为 0，则仅支持 LE 系统）。不影响生成的 wasm。
默认值：false
SAFE_HEAP¶
检查对堆的每次写入，例如，这将在本机构建中出现段错误时给出明确的错误（例如对 0 进行解引用）。有关执行的实际检查，请参阅 runtime_safe_heap.js。设置为值 1 以测试 Wasm+Wasm2JS 构建的安全行为。设置为值 2 以测试仅 Wasm 构建的安全行为。（值得注意的是，仅 Wasm 构建允许未对齐的内存访问。但是请注意，在某些架构上，未对齐的访问可能非常慢，因此仍然建议使用更严格的模式 1 验证你的代码）
默认值：0
SAFE_HEAP_LOG¶
记录所有 SAFE_HEAP 操作
默认值：false
EMULATE_FUNCTION_POINTER_CASTS¶
允许函数指针被转换，用运行时校正包装每个类型不正确的调用。这会增加开销，不应该正常使用。除了防止调用失败之外，这还会尽力转换值。我们使用 64 位 (i64) 来表示值，就像我们将发送的值写入内存并从同一内存中加载接收类型（使用截断/扩展/重新解释）一样。这意味着当类型不匹配时，模拟值可能不匹配（对于本机也是如此，实际上 - 这一切都是未定义的行为）。这种方法似乎足以支持 Python，这是激发此功能的主要用例。
默认值：false
EXCEPTION_DEBUG¶
在 emscriptened 代码中打印异常。
默认值：false
DEMANGLE_SUPPORT¶
如果为 1，则导出 demangle 和 stackTrace JS 库函数。
注意
此设置已弃用
默认值：false
LIBRARY_DEBUG¶
打印我们何时进入库调用（library*.js）。你也可以在运行时取消设置 runtimeDebug 以停止记录，并且可以在需要时设置它。在 C++ 中设置它的简单方法是
emscripten_run_script("runtimeDebug = ...;");
默认值：false
SYSCALL_DEBUG¶
打印所有 musl 系统调用，包括将它们的数字索引转换为字符串名称，这对于调试可能很方便。（其他系统调用没有编号，并且已经拥有明确的名称；使用 LIBRARY_DEBUG 获取所有系统调用的日志。）
默认值：false
SOCKET_DEBUG¶
记录套接字/网络数据传输。
默认值：false
DYLINK_DEBUG¶
记录动态链接器信息
默认值：0
FS_DEBUG¶
使用 library_fs.js 中的 trackingDelegate 注册文件系统回调
默认值：false
SOCKET_WEBRTC¶
除了可以通过“ -s”选项在编译时配置之外，WEBSOCKET_URL 和 WEBSOCKET_SUBPROTOCOL 设置也可以通过 Module 对象在运行时配置，例如 Module[‘websocket’] = {subprotocol: ‘base64, binary, text’}; Module[‘websocket’] = {url: ‘wss://’, subprotocol: ‘base64’}; 你可以将 'subprotocol' 设置为 null，如果你不想指定它，运行时配置可能很有用，因为它可以让应用程序选择多个不同的服务。
默认值：false
WEBSOCKET_URL¶
包含 WebSocket URL 前缀（ws:// 或 wss://）或完整 RFC 6455 URL 的字符串 - “ws[s]:” “//” 主机 [ “:” 端口 ] 路径 [ “?” 查询 ]。在（默认）情况下，仅指定前缀，URL 将从前缀 + 地址 + '：' + 端口构建，其中地址和端口从套接字 connect/bind/accept 调用中获取。
默认值：'ws://'
PROXY_POSIX_SOCKETS¶
如果为 1，POSIX 套接字 API 将使用本机桥接进程服务器代理来自浏览器到本机世界的套接字调用。
默认值：false
WEBSOCKET_SUBPROTOCOL¶
包含逗号分隔的 WebSocket 子协议列表的字符串，如 Sec-WebSocket-Protocol 标头中所示。你可以设置 'null'，如果你不想指定它。
默认值：'binary'
OPENAL_DEBUG¶
打印来自我们 OpenAL 实现的调试信息。
默认值：false
WEBSOCKET_DEBUG¶
如果为 1，则打印与来自 emscripten_web_socket_* 函数（位于 emscripten/websocket.h 中）的调用的调试信息。如果为 2，则还会跟踪通过套接字通信的字节。
默认值：false
GL_ASSERTIONS¶
为 GL 库中的错误情况添加额外的检查。可能会影响性能。
默认值：false
TRACE_WEBGL_CALLS¶
如果启用，则打印对 WebGL 上下文的 API 调用。（非常详细）
默认值：false
GL_DEBUG¶
启用更详细的 WebGL 相关操作的调试打印。与 LIBRARY_DEBUG 一样，这可以通过选项 GL.debug 在运行时进行切换。
默认值：false
GL_TESTING¶
启用后，在上下文中设置 preserveDrawingBuffer，以允许测试工作（但会增加开销）
默认值：false
GL_MAX_TEMP_BUFFER_SIZE¶
GL 模拟临时缓冲区有多大
默认值：2097152
GL_UNSAFE_OPTS¶
在 GL 模拟代码中启用一些可能不安全的优化
默认值：true
FULL_ES2¶
强制支持所有 GLES2 功能，而不仅仅是 WebGL 友好的子集。
默认值：false
GL_EMULATE_GLES_VERSION_STRING_FORMAT¶
如果为真，则 glGetString() 的 GL_VERSION 和 GL_SHADING_LANGUAGE_VERSION 将返回 OpenGL ES 格式的字符串“Open GL ES … (WebGL …)” 而不是 WebGL 格式。如果为假，则返回直接的 WebGL 格式字符串。将此设置为 true 以使 GL 上下文在这些版本字符串中看起来像 OpenGL ES 上下文（以牺牲一小部分额外代码大小为代价），并将此设置为 false 以使 GL 上下文看起来像 WebGL 上下文并从输出中节省一些字节。
默认值：true
GL_EXTENSIONS_IN_PREFIXED_FORMAT¶
如果为真，则所有 GL 扩展都以无前缀的 WebGL 扩展格式宣传，但也以桌面/移动 GLES/GL 扩展格式宣传，并带有 GL_ 前缀。
默认值：true
GL_SUPPORT_AUTOMATIC_ENABLE_EXTENSIONS¶
如果为真，则添加对自动启用所有 GL 扩展的支持，用于 GLES/GL 模拟目的。这会占用代码大小。如果将其设置为 0，则需要手动启用所需的扩展。
默认值：true
GL_SUPPORT_SIMPLE_ENABLE_EXTENSIONS¶
如果为真，则可以调用函数 emscripten_webgl_enable_extension() 来启用任何 WebGL 扩展。如果为假，为了节省代码大小，则不能调用 emscripten_webgl_enable_extension() 来启用任何“ANGLE_instanced_arrays”、“OES_vertex_array_object”、“WEBGL_draw_buffers”、“WEBGL_multi_draw”、“WEBGL_draw_instanced_base_vertex_base_instance” 或“WEBGL_multi_draw_instanced_base_vertex_base_instance” 扩展，但 html5.h 中的专用函数 emscripten_webgl_enable_*() 用于启用每个扩展。这样，代码大小只会针对实际使用的扩展增加。注意：如果将其设置为 0，则 GL_SUPPORT_AUTOMATIC_ENABLE_EXTENSIONS 也必须设置为零。
默认值：true
GL_TRACK_ERRORS¶
如果设置为 0，Emscripten GLES2->WebGL 翻译层不会跟踪 GLES2 中存在但在 WebGL 中不存在的 GL 错误类型。将此设置为 0 可以节省代码大小。（对于开发来说，最好保持为 1）
默认值：true
GL_SUPPORT_EXPLICIT_SWAP_CONTROL¶
如果为真，则 GL 上下文支持 explicitSwapControl 上下文创建标志。设置为 0 以节省不需要它的项目的少量空间。
默认值：false
GL_POOL_TEMP_BUFFERS¶
如果为真，则对 glUniform*fv 和 glUniformMatrix*fv 的调用将利用一组预先分配的临时缓冲区来处理常见的较小尺寸，以避免为 WebGL 1 生成临时垃圾。禁用此操作以优化 GL 库的生成大小，但以在 WebGL 1 中生成垃圾为代价。如果您只使用 WebGL 2 并且不支持 WebGL 1，则不需要此操作，您可以将其关闭。
默认值：true
GL_EXPLICIT_UNIFORM_LOCATION¶
如果为真，则启用对 EMSCRIPTEN_explicit_uniform_location WebGL 扩展的支持。请参阅 docs/EMSCRIPTEN_explicit_uniform_location.txt
默认值：false
GL_EXPLICIT_UNIFORM_BINDING¶
如果为真，则启用对 EMSCRIPTEN_uniform_layout_binding WebGL 扩展的支持。请参阅 docs/EMSCRIPTEN_explicit_uniform_binding.txt
默认值：false
USE_WEBGL2¶
已弃用。传递 -sMAX_WEBGL_VERSION=2 以目标 WebGL 2.0。
默认值：false
MIN_WEBGL_VERSION¶
指定要定位的最低 WebGL 版本。传递 -sMIN_WEBGL_VERSION=1 以启用定位 WebGL 1，传递 -sMIN_WEBGL_VERSION=2 以放弃对 WebGL 1.0 的支持。
默认值：1
MAX_WEBGL_VERSION¶
指定要定位的最高 WebGL 版本。传递 -sMAX_WEBGL_VERSION=2 以启用定位 WebGL 2。如果启用 WebGL 2，则某些 API（EGL、GLUT、SDL）将默认创建 WebGL 2 上下文（如果未指定版本）。请注意，即使您同时构建了 WebGL1 和 WebGL2 支持，如果用户的设备不支持 WebGL2，也不会自动回退到 WebGL1，因为这可能并不总是应用程序想要的结果。如果您想要这种回退，则可以尝试使用 WebGL2 创建上下文，如果失败，则尝试使用 WebGL1 创建上下文。
默认值：1
WEBGL2_BACKWARDS_COMPATIBILITY_EMULATION¶
如果为真，则在 WebGL 2 上下文上模拟一些 WebGL 1 功能，这意味着使用 WebGL 1/GLES 2 的应用程序可以初始化 WebGL 2/GLES3 上下文，但仍可以继续使用 WebGL2/GLES3 中不再支持的 WebGL1/GLES 2 功能。目前，这模拟了 GLSLES 1.00 shaders 中的 GL_EXT_shader_texture_lod 扩展，对无大小的内部纹理格式的支持，以及 GL_HALF_FLOAT_OES != GL_HALF_FLOAT 混淆。
默认值：false
FULL_ES3¶
强制支持所有 GLES3 功能，而不仅仅是 WebGL2 友好的子集。这会自动开启 FULL_ES2 和 WebGL2 支持。
默认值：false
LEGACY_GL_EMULATION¶
包含模拟各种桌面 GL 功能的代码。不完整但有些情况下有用，请参阅 http://kripken.github.io/emscripten-site/docs/porting/multimedia_and_graphics/OpenGL-support.html
默认值：false
GL_FFP_ONLY¶
如果您指定了 LEGACY_GL_EMULATION = 1 并且只在代码中使用固定功能管道，则也可以将其设置为 1 以向 GL 模拟层发出信号，表明它可以通过知道用户代码根本不使用着色器来执行额外的优化。如果 LEGACY_GL_EMULATION = 0，则此设置无效。
默认值：false
GL_PREINITIALIZED_CONTEXT¶
如果您希望在 JS 代码中提前创建 WebGL 上下文，请将其设置为 1 并将 Module['preinitializedWebGLContext'] 设置为预先创建的 WebGL 上下文。随后的 WebGL 初始化将使用此 GL 上下文进行渲染。
默认值：false
USE_WEBGPU¶
启用对 WebGPU 的支持（通过“webgpu/webgpu.h”。
默认值：false
STB_IMAGE¶
启用 stb-image 的构建，stb-image 是一个用于解码图像的微型公共领域库，允许在不使用浏览器内置解码器的情况下解码图像。好处是可以同步完成此操作，但是速度不会像浏览器本身那样快。启用后，将从 IMG_Load 和 IMG_Load_RW 自动使用 stb-image。您也可以直接调用 stbi_* 函数。
默认值：false
GL_DISABLE_HALF_FLOAT_EXTENSION_IF_BROKEN¶
从 Safari 8（WebGL 在 Safari 中引入的地方）开始，OES_texture_half_float 和 OES_texture_half_float_linear 扩展已损坏，在用作源纹理时无法正常工作。请参阅 https://bugs.webkit.org/show_bug.cgi?id=183321、https://bugs.webkit.org/show_bug.cgi?id=169999、https://stackoverflow.com/questions/54248633/cannot-create-half-float-oes-texture-from-uint16array-on-ipad
默认值：false
GL_WORKAROUND_SAFARI_GETCONTEXT_BUG¶
解决 Safari WebGL 问题：在成功获取画布上的 WebGL 上下文后，调用 .getContext() 将始终返回该上下文，而与传递了哪个“webgl”或“webgl2”上下文版本无关。请参阅 https://bugs.webkit.org/show_bug.cgi?id=222758 和 https://github.com/emscripten-core/emscripten/issues/13295。如果您知道此问题不会影响您，请将其设置为 0 以强制禁用此解决方法。
默认值：true
GL_ENABLE_GET_PROC_ADDRESS¶
如果为 1，则链接支持 glGetProcAddress() 功能。在 WebGL 中，glGetProcAddress() 会造成相当大的代码大小和性能影响，因为 WebGL 本身不提供这种功能，必须对其进行模拟。不建议使用 glGetProcAddress()。如果您仍然需要使用它（例如在移植现有渲染器时），则可以链接 -sGL_ENABLE_GET_PROC_ADDRESS=1 以获得对该功能的支持。
默认值：true
JS_MATH¶
使用 JavaScript 数学函数，如 Math.tan。这可以节省代码大小，因为我们可以避免发送编译后的 musl 代码。但是，它可能非常慢，因为它会调用 JS。它还可能给出不同的结果，因为 JS 数学的规范与 libc 有所不同，并且在不同的浏览器之间也会有所不同。
默认值：false
POLYFILL_OLD_MATH_FUNCTIONS¶
如果设置，则启用 Math.clz32、Math.trunc、Math.imul、Math.fround 的填充。
默认值：false
LEGACY_VM_SUPPORT¶
将此设置为启用对旧 JavaScript 引擎的兼容性模拟。这将为您提供代码在任何地方都能工作的最高可能性，即使在罕见的旧浏览器和 shell 环境中也是如此。具体来说
为 Math.clz32、Math.trunc、Math.imul、Math.fround 添加填充。（-sPOLYFILL_OLD_MATH_FUNCTIONS）
禁用 WebAssembly。（必须与 -sWASM=0 配合使用）
将 MIN_X_VERSION 设置调整为 0 以包括对所有浏览器版本的支持。
在 zeroMemory 实用程序函数中，如果需要，请避免 TypedArray.fill。
您也可以分别配置上述选项。
默认值：false
ENVIRONMENT¶
指定 JS 输出能够运行的运行时环境。为了最大限度地提高可移植性，可以将其配置为支持所有环境，或者可以将其限制为减少总代码大小。支持的环境包括
‘web’ - 正常的网络环境。
‘webview’ - 就像 web 一样，但在类似 Cordova 的 webview 中；几乎在所有地方都被认为与“web”相同。
‘worker’ - 网络工作者环境。
‘node’ - Node.js。
‘shell’ - 类似 d8、js 或 jsc 的 JS shell。
此设置可以是这些环境的逗号分隔列表，例如“web,worker”。如果这是空字符串，则支持所有环境。
请注意，此处识别的环境集与我们在运行时使用 ENVIRONMENT_IS_* 识别的环境集不同。具体来说
我们在运行时检测我们是否是一个 pthread，但这对 worker 设置有效，对主文件无效，因此在指定此处时没有意义。
webview 目标基本上是 web 的一个子集。它必须与 web 一起指定（例如“web,webview”），我们只在编译时将其用于代码生成，没有运行时行为更改。
请注意，默认情况下，我们不包含“shell”环境，因为直接使用 d8、js、jsc 非常罕见。
默认值：‘web,webview,worker,node’
LZ4¶
启用此选项以支持 lz4 压缩的文件包。它们以压缩形式存储在内存中，并按需解压缩，避免一次将所有解压缩后的数据存储在内存中。如果您单独运行文件打包程序，则仍然需要使用此标志构建主程序，并且还需要将 –lz4 传递给文件打包程序。（您也可以在客户端手动压缩一个，使用 LZ4.loadPackage()，但不太推荐这样做。）限制
LZ4 压缩的文件仅在需要时才解压缩，因此它们不可用于特殊预加载操作，例如使用浏览器编解码器预解码图像、preloadPlugin 等。
LZ4 文件是只读的。
默认值：false
DISABLE_EXCEPTION_CATCHING¶
禁用生成代码以实际捕获异常。此禁用默认情况下处于启用状态，因为异常的开销目前在大小和速度方面非常高（将来，wasm 应该改进这一点）。当禁用异常时，如果实际发生异常，则不会捕获该异常，程序将停止（因此这不会引入静默失败）。
注意
这将删除捕获异常，这是速度的主要问题，但是您应该使用 -fno-exceptions 构建源文件以真正摆脱所有异常代码开销，因为它可能包含从未捕获的抛出异常（例如，仅使用 std::vector 就会出现这种情况）。-fno-rtti 也可以有所帮助。
此选项与 EXCEPTION_CATCHING_ALLOWED 互斥。
此选项仅适用于 Emscripten（基于 JavaScript）的异常处理，并不控制本机 Wasm 异常处理。
[编译 + 链接] - 在编译时影响用户代码，在链接时影响系统库
默认值：1
EXCEPTION_CATCHING_ALLOWED¶
启用捕获异常，但仅在列出的函数中。此选项的作用类似于 DISABLE_EXCEPTION_CATCHING=0 的更精确版本。
此选项与 DISABLE_EXCEPTION_CATCHING 互斥。
此选项仅适用于 Emscripten（基于 JavaScript）的异常处理，并不控制本机 Wasm 异常处理。
[编译 + 链接] - 在编译时影响用户代码，在链接时影响系统库
默认值：[]
DISABLE_EXCEPTION_THROWING¶
内部：跟踪 Emscripten 是否应该链接异常抛出（C++ 'throw'）支持库。不需要直接设置它，而是将 -fno-exceptions 传递给构建以禁用异常支持。（这基本上是 -fno-exceptions，但在最终链接时进行检查，而不是在各个 .cpp 文件编译时进行检查）如果程序确实包含抛出代码（一些源文件没有使用 -fno-exceptions 编译），并且此标志在链接时设置，那么您将在未定义的符号上得到错误，因为异常抛出代码没有链接进来。如果是这种情况，您应该取消设置该选项（如果您确实想要异常）或修复源文件的编译，以便确实不使用异常）。TODO(sbc)：移动到 settings_internal（目前由于在测试代码中的使用而被阻止）。
此选项仅适用于 Emscripten（基于 JavaScript）的异常处理，并不控制本机 Wasm 异常处理。
默认值：false
EXPORT_EXCEPTION_HANDLING_HELPERS¶
通过将必要的符号添加到 EXPORTED_FUNCTIONS，使异常消息打印函数 'getExceptionMessage' 在 JS 库中可用。
这适用于 Emscripten EH 和 Wasm EH。当您从 JS 捕获异常时，它会在 Emscripten EH 的情况下为您提供用户抛出的值，在 Wasm EH 的情况下提供 WebAssembly.Exception 对象。'getExceptionMessage' 在 Emscripten EH 的情况下接受用户抛出的值，在 Wasm EH 的情况下接受 WebAssembly.Exception 对象，这意味着在两种情况下，您都可以将捕获的异常直接传递给该函数。
当与 Wasm EH 一起使用时，此选项还会在 JS 库中提供以下函数
getCppExceptionTag：返回 C++ 标记
getCppExceptionThrownObjectFromWebAssemblyException：给定 WebAssembly.Exception 对象，返回 Wasm 内存中实际用户抛出的 C++ 对象地址。
设置此选项还会在 JS 库中添加引用计数增加和减少函数（'incrementExceptionRefcount' 和 'decrementExceptionRefcount'），因为如果您从 JS 捕获异常，您可能需要手动操作引用计数以避免内存泄漏。您需要执行的操作取决于您使用的 EH 类型 (https://github.com/emscripten-core/emscripten/issues/17115 )。
在 test/test_core.py 中查看 test_EXPORT_EXCEPTION_HANDLING_HELPERS 以了解示例用法。
默认值：false
EXCEPTION_STACK_TRACES¶
启用此功能时，异常将包含堆栈跟踪，未捕获的异常将在退出时显示堆栈跟踪。当 ASSERTIONS 启用时，此功能默认为 true。此选项适用于希望异常的堆栈跟踪但又不想使用 ASSERTIONS 可能产生的其他开销的用户。此选项意味着 EXPORT_EXCEPTION_HANDLING_HELPERS。
默认值：false
WASM_EXNREF¶
为带有 exnref 的新的 Wasm 异常处理提案发出指令，该提案已于 2023 年 10 月被采纳。新提案的实施仍在进行中，此功能目前处于实验阶段。
默认值：false
NODEJS_CATCH_EXIT¶
Emscripten 抛出一个 ExitStatus 异常以在调用 exit() 时展开。如果不启用此设置，这可能会显示为顶级未处理异常。
启用此设置后，将使用全局未捕获异常处理程序来捕获和处理 ExitStatus 异常。但是，这意味着所有其他未捕获的异常也会被捕获并重新抛出，这并不总是可取的。
默认值：false
NODEJS_CATCH_REJECTION¶
在 node 中捕获未处理的拒绝。这只会影响 15 之前的 node 版本。如果没有此功能，旧版本的 node 会打印警告，但会以零返回值退出。启用此设置后，我们将处理任何未处理的拒绝并抛出异常，这会导致进程立即以非 0 返回值退出。这在 Node 15 及更高版本中不需要，因此如果 MIN_NODE_VERSION 为 150000 或更高，则此设置将默认为 false。
默认值：true
ASYNCIFY¶
是否在编译的代码中支持异步操作。这使得从 C/C++ 中看起来同步的代码调用 JS 函数成为可能。
1（默认值）：运行 binaryen 的 Asyncify 传递以使用 asyncify 转换代码。这最终会发出一个普通的 wasm 文件，因此它可以在任何地方使用，但它在代码大小和速度方面有很大的开销。见 https://emscripten.webassembly.net.cn/docs/porting/asyncify.html
2（已弃用）：改用
-sJSPI。
默认值：0
ASYNCIFY_IMPORTS¶
除了 emscripten 定义的默认导入（如 emscripten_sleep）之外，还可以执行异步操作的导入。如果您添加更多内容，则需要在此处提及它们，否则它们将无法工作（在 ASSERTIONS 构建中会显示错误）。请注意，此列表过去包含默认列表，这意味着在添加您自己的内容时，您必须列出它们；现在默认列表会自动添加。
默认值：[]
ASYNCIFY_IGNORE_INDIRECT¶
间接调用是否可以在展开/回溯期间位于堆栈上。如果您知道它们不能，那么设置此选项将非常有用，因为否则 asyncify 必须假设间接调用可以到达几乎所有地方。
默认值：false
ASYNCIFY_STACK_SIZE¶
asyncify 堆栈的大小 - 用于存储展开/回溯信息的区域。它必须足够大以存储调用堆栈和局部变量。如果它太小，您将看到一个 wasm 陷阱，因为它执行了“不可到达”的指令。在这种情况下，您应该增加此大小。
默认值：4096
ASYNCIFY_REMOVE¶
如果提供了 Asyncify 删除列表，那么即使看起来它们需要，列表中的函数也不会被插桩。如果您了解整个程序分析所不知道的事情，例如，如果您知道某些间接调用是安全的并且不会展开，那么这将非常有用。但是，如果您弄错了列表，程序就会崩溃（在生产构建中，用户输入可能会到达您在测试期间错过的代码路径，因此很难知道您是否做对了），因此不建议这样做，除非您确实知道自己在做什么，并且需要优化每一分速度和大小。
此列表中的名称来自 WebAssembly Names 部分。wasm 后端将以人类可读的形式发出这些名称，而不是典型的 C++ 命名。例如，您应该编写 Struct::func() 而不是 _ZN6Struct4FuncEv。C 也与 C++ 不同，因为 C 名称不以参数结尾；因此，C++ 中的 foo(int) 将显示为 C 中的 foo（C++ 有参数是因为它需要区分重载函数）。如果您在列表中找不到名称，您将在控制台中看到警告（这不是错误，因为内联等可能会导致更改，这意味着单个列表无法同时适用于 -O0 和 -O1 构建等）。您可以检查 wasm 二进制文件以查找实际名称，无论是直接还是使用 wasm-objdump 或 wasm-dis 等。
支持简单的 * 通配符匹配。
为了避免处理操作系统 shell 或构建系统转义中的限制，可以使用以下替换
' ' ->
.，&->#,,->?.
也就是说，函数 “foo(char const*, int&)” 可以作为 “foo(char.const*?.int#)” 在命令行中输入。
注意：空格是函数签名的组成部分！即“foo(char const *, int &)” 不会匹配“foo(char const *, int&)”，并且“foo(const char*, int &)” 也不会匹配。
默认值：[]
ASYNCIFY_ADD¶
Asyncify 添加列表中的函数将添加到已插桩函数列表中，也就是说，即使 asyncify 认为它们不需要插桩，它们也会被插桩。由于默认情况下所有内容都将以最安全的方式进行插桩，因此只有在您使用 IGNORE_INDIRECT 并使用此列表修复确实需要插桩的某些间接调用时，这才是有用的。
有关名称的说明，请参阅有关 ASYNCIFY_REMOVE 的说明，包括通配符匹配和字符替换。
默认值：[]
ASYNCIFY_PROPAGATE_ADD¶
如果启用，插桩状态将从添加列表中传播，即它们的调用者、它们的调用者的调用者，等等。如果禁用，则所有调用者都必须手动添加到添加列表中（就像仅列表一样）。
默认值：true
ASYNCIFY_ONLY¶
如果提供了 Asyncify 仅列表，则仅列表中的函数将被插桩。与删除列表一样，如果弄错了，您的应用程序就会崩溃。
有关名称的说明，请参阅有关 ASYNCIFY_REMOVE 的说明，包括通配符匹配和字符替换。
默认值：[]
ASYNCIFY_ADVISE¶
如果启用，将输出哪些函数已插桩以及原因。
默认值：false
ASYNCIFY_LAZY_LOAD_CODE¶
允许延迟代码加载：在编写 emscripten_lazy_load_code() 的地方，我们将暂停执行，加载其余代码，然后恢复。
默认值：false
ASYNCIFY_DEBUG¶
来自 asyncify 内部机制的运行时调试日志记录。
1：最小日志记录。
2：详细日志记录。
默认值：0
ASYNCIFY_EXPORTS¶
已弃用，请改用 JSPI_EXPORTS。
注意
此设置已弃用
默认值：[]
JSPI¶
使用 VM 支持 JavaScript Promise Integration 提案。这允许异步操作在不修改 wasm 的开销下发生。目前这是实验性的，因为规范讨论仍在进行中，请参阅 https://github.com/WebAssembly/js-promise-integration/ TODO：记录在此模式下哪些以下标志仍然相关（例如 IGNORE_INDIRECT 等不需要）。
默认值：0
JSPI_EXPORTS¶
一个导出模块函数列表，它们将是异步的。每个导出将返回一个 Promise，它将使用结果解析。任何将调用异步导入（在 JSPI_IMPORTS 中列出）的导出都必须包含在此处。
默认情况下，这包括 main。
默认值：[]
JSPI_IMPORTS¶
一个导入模块函数列表，它们可能会执行异步工作。导入的函数在执行异步工作时应该返回一个 Promise。
请注意，使用 --js-library 时，可以在库中使用 <function_name>_async:: true 来标记该函数，而不是此设置。
默认值：[]
EXPORTED_RUNTIME_METHODS¶
默认情况下，在模块上导出的运行时元素。我们过去在这里导出很多东西，但现在都删除了。您应该使用 EXPORTED_RUNTIME_METHODS 来导出您想要从运行时导出的内容。请注意，该名称可能略微误导，因为这是针对任何 JS 库元素，而不仅仅是方法。例如，我们可以通过将“FS”包含在此列表中来导出 FS 对象。
默认值：[]
EXTRA_EXPORTED_RUNTIME_METHODS¶
已弃用，请改用 EXPORTED_RUNTIME_METHODS。
注意
此设置已弃用
默认值：[]
INCOMING_MODULE_JS_API¶
我们关注的 JS 对象中传入值的列表。如果一个值不在此列表中，那么我们不会发出代码来检查您是否在 Module 对象上提供了它。例如，如果您有以下内容
var Module = {
print: (x) => console.log('print: ' + x),
preRun: [() => console.log('pre run')]
};
那么 MODULE_JS_API 必须包含 'print' 和 'preRun'；如果没有，那么我们可能不会发出代码来读取和使用该值。换句话说，此选项允许您在编译时静态设置您将在运行时提供的 Module JS 值的列表，以便编译器可以更好地优化。
将此列表设置为 []，或者至少设置您实际使用的简短而简洁的名称集，对于减少代码大小非常有用。默认情况下，该列表包含一组常用的符号。
FIXME：如果我们想要所有内容，这是否应该为 0？
默认值：(多行值，请参阅 settings.js)
CASE_INSENSITIVE_FS¶
如果设置为非零值，则提供的虚拟文件系统将被视为不区分大小写，就像 Windows 和 macOS 一样。如果设置为 0，则 VFS 区分大小写，就像 Linux 上一样。
默认值：false
FILESYSTEM¶
如果设置为 0，则不会构建任何文件系统支持。如果您只是进行纯计算，而不是读取文件或使用任何流（包括 fprintf 和其他 stdio.h 东西）或任何相关内容，这将很有用。一个例外是，对 printf 和 puts 有部分支持，虽然是粗略的。如果检测到系统调用使用情况（这是静态的）不需要完整的文件系统，编译器将自动设置此选项。如果您仍然需要文件系统支持，请使用 FORCE_FILESYSTEM
默认值：true
FORCE_FILESYSTEM¶
即使静态看起来没有使用，也会使完整的文件系统支持被包含。例如，如果您的 C 代码不使用任何文件，但您包含了一些执行此操作的 JS，您可能需要此选项。
默认值：false
NODERAWFS¶
启用对 NODERAWFS 文件系统后端的支持。这是一个特殊的后端，因为它将所有正常的文件系统访问替换为直接的 Node.js 操作，而无需执行 FS.mount()，并且此后端仅适用于 Node.js。初始工作目录将与 process.cwd() 相同，而不是 VFS 根目录。因为此模式直接使用 Node.js 访问您操作系统上的真实本地文件系统，所以代码不一定可以在操作系统之间移植 - 它将像 Node.js 程序一样可移植，这意味着在底层操作系统处理权限和错误等方面可能存在差异。是显而易见的。
默认值：false
NODE_CODE_CACHING¶
这会将编译后的 wasm 模块保存在名为 $WASM_BINARY_NAME.$V8_VERSION.cached 的文件中，并在后续运行时加载它。这会缓存 node 中从 v8 编译的 wasm 代码，这可以节省后续运行时的编译时间，从而使它们启动速度更快。node 中使用的 V8 版本包含在缓存名称中，以便我们不会尝试加载来自其他版本的缓存代码，这会导致静默失败（似乎加载正常，但我们确实重新编译了）。
唯一已知可以肯定工作的版本是 node 12.9.1，因为这已经退化，请参阅 https://github.com/nodejs/node/issues/18265#issuecomment-622971547
.cached 文件的默认位置与之前提到的 wasm 二进制文件并排。如果它位于只读目录中，您可能需要将它们放在其他地方。您可以使用 locateFile() 钩子来做到这一点。
默认值：false
EXPORTED_FUNCTIONS¶
明确导出的符号。这些符号通过 LLVM 死代码消除保持活动状态，并且即使在运行闭包编译器（在“Module”上）之后，也能够从生成的代码之外访问。此处列出的本机符号需要 _ 前缀。
默认情况下，如果未在命令行上指定此设置，则 _main 函数将被隐式导出。在 STANDALONE_WASM 模式下，默认导出是 __start（或 __initialize 如果指定了 –no-entry）。
JS 库符号也可以添加到此列表中（没有前导 $）。
默认值：[]
EXPORT_ALL¶
如果为 true，我们将在 Module 对象上导出 JS 中存在的所有符号。这不会影响哪些符号将存在 - 它不会阻止 DCE 或导致任何内容被包含在链接中。它只对最终出现在 JS 文件中的所有 X 执行 Module['X'] = X;。这对于在 Module 上导出 JS 库函数很有用，例如动态链接。
默认值：false
EXPORT_KEEPALIVE¶
如果为 true，我们将在 Module 对象上导出 JS 中存在的所有符号。它只执行 Module['X'] = X;
默认值：true
RETAIN_COMPILER_SETTINGS¶
记住这些设置的值，并使它们可以通过 getCompilerSetting 和 emscripten_get_compiler_setting 访问。要查看保留的内容，请在生成的代码中查找 compilerSettings。
默认值：false
DEFAULT_LIBRARY_FUNCS_TO_INCLUDE¶
我们默认包含的 JS 库元素（用 JS 实现的 C 函数）。如果您想确保 JS 编译器包含某件事，请将其添加到这里。例如，如果您没有从 C 中使用某些 emscripten_* C API 调用，但您想从 JS 中调用它，请将其添加到这里。请注意，该名称可能略微误导，因为这是针对任何 JS 库元素，而不仅仅是函数。例如，您可以通过将“$Browser”添加到此列表中来包含 Browser 对象。
如果您想包含和导出 JS 库符号，只需将其添加到 EXPORTED_FUNCTIONS 中，而无需将其添加到 DEFAULT_LIBRARY_FUNCS_TO_INCLUDE 中。
默认值：[]
INCLUDE_FULL_LIBRARY¶
包含所有 JS 库函数，而不是 DEFAULT_LIBRARY_FUNCS_TO_INCLUDE + 生成的代码使用的任何函数的总和。当动态加载（即 dlopen）使用主模块中未使用的运行时库函数的模块时，需要此选项。请注意，这仅适用于 js 库，不适用于 C。您需要主文件来包含所有需要的 C 库。例如，如果一个模块使用 malloc 或 new，您还需要在主文件中使用它们才能将 malloc 用于该模块。
默认值：false
RELOCATABLE¶
如果设置为 1，我们将在 LLVM 后端发出可重定位代码；全局变量和函数指针都由（分别为 gb 和 fp）偏移。对于 SIDE_MODULE 或 MAIN_MODULE 自动设置。
注意
适用于链接和编译期间
默认值：false
MAIN_MODULE¶
主模块是一个以允许我们将其在运行时链接到侧模块的方式编译的文件。
1：普通主模块。
2：DCE’d 主模块。我们通常会消除死代码。如果侧模块需要来自主模块的内容，则由您确保其保持活动状态。
注意
适用于链接和编译期间
默认值：0
SIDE_MODULE¶
对应于 MAIN_MODULE（也支持模式 1 和 2）
注意
适用于链接和编译期间
默认值：0
RUNTIME_LINKED_LIBS¶
已弃用，请直接在命令行上列出共享库。
注意
此设置已弃用
默认值：[]
BUILD_AS_WORKER¶
如果设置为 1，则这是一个工作库，一种特殊类型的库，在工作库中运行。请参阅 emscripten.h
默认值：false
PROXY_TO_WORKER¶
如果设置为 1，我们将项目构建成一个将在工作库中运行的 js 文件，并生成一个将输入和输出代理到/从其到/来自其的 html 文件。
默认值：false
PROXY_TO_WORKER_FILENAME¶
如果设置，则为主线程加载的脚本文件名。如果您的项目没有立即运行主 emscripten 生成的脚本，而是在执行一些设置后才运行，这将很有用。
默认值：‘’
PROXY_TO_PTHREAD¶
如果设置为 1，则在真实 main() 之间编译一个小型的存根 main()，它调用 pthread_create() 以在 pthread 中运行应用程序 main()。这也可以是应用程序手动执行的操作，如果需要，此选项作为便利提供。
main() 运行的 pthread 在所有方面都是一个正常的 pthread，唯一的区别是它的堆栈大小与主线程通常具有的堆栈大小相同，即 STACK_SIZE。这使得在 PROXY_TO_PTHREAD 和非 PROXY_TO_PTHREAD 模式之间轻松切换，因为 main() 始终获得相同的堆栈量。
如果存在，并且启用了 OFFSCREENCANVAS_SUPPORT，则会代理 Module[‘canvas’]。这必须发生，因为这是唯一的机会 - 此浏览器主线程执行该线程上发生的唯一 pthread_create 调用，因此这是从那里传输画布的唯一机会。
默认值：false
LINKABLE¶
如果设置为 1，则此文件可以与其他文件链接，无论是作为共享库还是作为调用共享库的主文件。为了启用这一点，我们不会将所有符号内部化并剔除未使用的符号，换句话说，我们不会删除未使用的函数和全局变量，这些全局变量可能被我们链接的另一个模块使用。
MAIN_MODULE 和 SIDE_MODULE 都暗示这一点，因此通常不需要显式设置它。请注意，MAIN_MODULE 和 SIDE_MODULE 模式 2 不设置此选项，因此我们仍然对它们执行正常的 DCE，在这种情况下，您必须使用导出自己使相关内容保持活动状态。
默认值：false
STRICT¶
Emscripten 的“严格”构建模式：放弃支持任何已弃用的构建选项。设置环境变量 EMCC_STRICT=1 或传递 -sSTRICT 来测试代码库是否以向前兼容的方式很好地构建。此选项启用的更改
C 定义 EMSCRIPTEN 未定义（__EMSCRIPTEN__ 始终定义，并且是正确的使用方法）。
STRICT_JS 已启用。
IGNORE_MISSING_MAIN 已禁用。
AUTO_JS_LIBRARIES 已禁用。
AUTO_NATIVE_LIBRARIES 已禁用。
DEFAULT_TO_CXX 已禁用。
USE_GLFW 默认设置为 0 而不是 2。
ALLOW_UNIMPLEMENTED_SYSCALLS 已禁用。
INCOMING_MODULE_JS_API 默认设置为为空。
注意
适用于链接和编译期间
默认值：false
IGNORE_MISSING_MAIN¶
允许程序与 main 符号链接或不链接。如果禁用此选项，则必须提供 main 符号或通过传递 --no-entry 或不包含 _main 的 EXPORTED_FUNCTIONS 列表来明确选择退出。
默认值：true
STRICT_JS¶
在生成的 JS 中添加 "use strict;"
默认值：false
WARN_ON_UNDEFINED_SYMBOLS¶
如果设置为 1，我们将对任何未由 library_*.js 文件解析的未定义符号发出警告。请注意，在大项目中，未实现所有内容是很常见的，当你了解到哪些内容实际上不会被调用时（并且不想弄乱现有的构建系统），并且函数可能会在稍后实现，比如在 –pre-js 中，因此你可能希望使用 -s WARN_ON_UNDEFINED_SYMBOLS=0 来禁用这些警告，如果它们让你感到厌烦。另请参阅 ERROR_ON_UNDEFINED_SYMBOLS。EXPORTED_FUNCTIONS 中列出的任何未定义符号也将被报告。
默认值：true
ERROR_ON_UNDEFINED_SYMBOLS¶
如果设置为 1，我们将对任何未定义的符号给出链接时错误（请参阅 WARN_ON_UNDEFINED_SYMBOLS）。要允许在链接时使用未定义的符号，请将其设置为 0，在这种情况下，如果调用未定义的函数，则会发生运行时错误。EXPORTED_FUNCTIONS 中列出的任何未定义符号也将被报告。
默认值：true
SMALL_XHR_CHUNKS¶
对 Web Workers 中的二进制同步 XHR 使用小块大小。用于测试。请参阅 runner.py 和 library.js 中的 test_chunked_synchronous_xhr。
默认值：false
HEADLESS¶
如果为 1，将包含试图“伪造”浏览器环境的垫片代码，以便让你在 shell 中运行浏览器程序（例如，使用 SDL）。显然什么都不会呈现，但这对于基准测试和调试（如果实际渲染不是问题）可能很有用。请注意，垫片代码非常不完整 - 很难伪造整个浏览器！ - 因此，请降低对它起作用的期望。
默认值：false
DETERMINISTIC¶
如果为 1，我们将强制 Date.now()、Math.random 等返回确定性结果。这也尝试使跨机器和环境的执行确定性，例如，不根据浏览器的语言设置执行任何不同操作（这意味着你可以在不同的浏览器中获得不同的结果，或者在浏览器和节点中获得不同的结果）。有利于将构建进行比较以进行调试目的（以及其他任何目的）。
默认值：false
MODULARIZE¶
默认情况下，我们将所有代码以直接的方式输出到输出 .js 文件中。这意味着如果你在网页中的脚本标签中加载它，它将使用全局作用域。如果设置了 MODULARIZE，我们将改为发出包裹在返回 Promise 的函数中的代码。Promise 在可以安全运行编译代码时，使用模块实例解析，类似于 onRuntimeInitialized 回调。在使用 MODULARIZE 时，你不需要使用 onRuntimeInitialized 回调。
（如果 WASM_ASYNC_COMPILATION 关闭，即如果编译是同步的，那么返回 Promise 就没有意义，而是返回 Module 对象本身，它已准备好使用。）
函数的默认名称为 Module，但可以使用 EXPORT_NAME 选项更改。我们建议将其重命名为更典型的工厂函数名称，例如 createModule。
你像这样使用工厂函数
const module = await EXPORT_NAME();
或
let module;
EXPORT_NAME().then(instance => {
module = instance;
});
工厂函数接受 1 个参数，一个包含模块实例的默认值的object
const module = await EXPORT_NAME({ option: value, ... });
请注意括号 - 我们正在调用 EXPORT_NAME 以实例化模块。这允许你创建模块的多个实例。
请注意，在 MODULARIZE 模式下，我们不会为默认值寻找全局 Module 对象。默认值必须作为参数传递给工厂函数。
在 MINIMAL_RUNTIME 模式下提供的默认 .html shell 文件将自动创建一个单例实例，以便在页面上运行应用程序。（请注意，它在不使用前面提到的 Promise API 的情况下执行此操作，因此如果告诉 emcc 发出 .html 输出，则 .js 文件中甚至不会发出 Promise 的代码。）传统的运行时模式提供的默认 .html shell 文件仅与 MODULARIZE=0 模式兼容，因此在使用传统的运行时构建时，你应该提供自己的 html shell 文件，以便在使用 MODULARIZE=1 构建时执行实例化。（有关更多详细信息，请参阅 https://github.com/emscripten-core/emscripten/issues/7950）
如果你添加 –pre-js 或 –post-js 文件，它们将与其余发出的代码一起包含在工厂函数中，以便与其一起优化。
如果你想在所有生成的代码之外，包括工厂函数，包含代码，可以使用 –extern-pre-js 或 –extern-post-js。虽然 –pre-js 和 –post-js 恰好能在非 MODULARIZE 模式下做到这一点，但它们的预期用途是添加与其余发出的代码一起优化的代码，从而实现更好的死代码消除和缩小。
默认值：false
EXPORT_ES6¶
使用 ES6 模块导出而不是 UMD 导出。必须启用 MODULARIZE 才能使用 ES6 导出，并且如果尚未设置，则隐式启用。
如果输出后缀设置为 ‘mjs’，则会隐式启用此选项。
默认值：false
USE_ES6_IMPORT_META¶
使用 ES6 模块相对导入功能‘import.meta.url’ 自动检测 WASM 模块路径。它可能在旧的浏览器/工具链上不受支持。当目标为 Node.js 时，此设置可能无法禁用（-sENVIRONMENT=*node*）。
默认值：true
EXPORT_NAME¶
全局变量，用于将模块导出为没有标准化模块加载系统的环境（例如浏览器和 SM shell）。
默认值：‘Module’
DYNAMIC_EXECUTION¶
当设置为 0 时，我们不会发出 eval() 和 new Function()，这会禁用某些功能（如果尝试使用会导致运行时错误），但允许发出的代码在禁止动态代码执行的地方可接受（Chrome 打包应用程序、特权 Firefox 应用程序等）。在开发针对特权或经过认证的执行环境的 Emscripten 应用程序时，请传递此标志，请参阅 Firefox 内容安全策略 (CSP) 网页以了解详细信息：https://mdn.org.cn/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src，尤其是 ‘unsafe-eval’ 和 ‘wasm-unsafe-eval’ 策略。
当设置此标志时，以下功能（链接器标志）不可用
RELOCATABLE：loadDynamicLibrary 函数需要 eval()。
以及一些功能在需要时可能会回退到较慢的代码路径：Embind：使用 eval() 对函数进行 jit 以提高速度。
此外，当设置 DYNAMIC_EXECUTION=0 时，以下 Emscripten 运行时函数不可用，并且尝试调用它们将引发异常
emscripten_run_script()，
emscripten_run_script_int()，
emscripten_run_script_string()，
dlopen()，
ccall() 和 cwrap() 函数仍然可用，但它们仅限于调用已在 Module 对象中预先导出的函数。
当设置 -sDYNAMIC_EXECUTION=2 时，尝试调用 eval() 会降级为警告，而不是引发异常。
默认值：1
BOOTSTRAPPING_STRUCT_INFO¶
我们是否处于生成 struct_info 引导阶段
默认值：false
EMSCRIPTEN_TRACING¶
添加一些对 emscripten 跟踪 API 的调用
注意
适用于链接和编译期间
默认值：false
USE_GLFW¶
指定正在链接的 GLFW 版本。仅当你在链接 GLFW 库时才相关。有效选项是 2（表示 GLFW2）和 3（表示 GLFW3）。
默认值：0
WASM¶
是否将代码编译为 WebAssembly。将其设置为 0 以将代码编译为 JS，而不是 wasm。
指定 -sWASM=2 以同时针对 WebAssembly 和 JavaScript。在该构建模式下，会生成两个文件 a.wasm 和 a.wasm.js，并且在运行时，如果浏览器/shell 支持，则会加载 WebAssembly 文件。否则，将使用 .wasm.js 备用文件。
如果启用了 WASM=2 并且浏览器无法编译 WebAssembly 模块，则页面将以 Wasm2JS 模式重新加载。
默认值：1
STANDALONE_WASM¶
STANDALONE_WASM 表示我们希望发出一个可以在没有 JavaScript 的情况下运行的 wasm 文件。该文件将尽可能使用标准 API（如 wasi）来实现这一点。
此选项不能保证 wasm 可以独立使用 - 如果你使用没有非 JS 替代方案的 API，我们仍然会使用这些 API（例如，在撰写本文时，OpenGL）。这让你可以选择查看哪些 API 缺失，以及如果你正在为自定义 wasi 嵌入进行编译，则可以将这些 API 添加到你的嵌入中。
我们可能仍然会使用此标志发出 JS，但 JS 应该只是一种在 Web 或 Node.js 上方便运行 wasm 的方法，你可以在没有该 JS 的情况下自己运行 wasm（同样，除非你使用没有非 JS 替代方案的 API），在 wasm 运行时（如 wasmer 或 wasmtime）中。
请注意，即使没有此选项，我们也会尽可能使用 wasi 等系统调用。此选项更改的是，即使这意味着与 JS 大小权衡，我们也会这样做。例如，当设置此选项时，我们不会导入 Memory - 导入它对于 JS 很有用，因此 JS 可以开始使用它，甚至在 wasm 加载之前，但在 wasi 和其他仅 wasm 环境中，预期是在 wasm 本身中创建内存。这样做可以防止一些可能的 JS 优化，因此我们仅在该标志之后执行此操作。
当设置此标志时，我们不会将 JS 接口合法化，因为 wasm 旨在在 wasm VM 中运行，它可以直接处理 i64。如果我们将其合法化，wasm VM 将无法识别 API。但是，这意味着如果你使用具有 i64 的 JS API，则发出的可选 JS 不会运行。你可以使用 WASM_BIGINT 选项来避免该问题，方法是使用 BigInts 表示 i64，这意味着我们不需要为 JS 合法化（但这需要一个足够新的 JS VM）。
独立构建默认情况下需要 main 入口点。如果您想构建一个库（也称为反应器），而不是传递 --no-entry。
默认值：false
BINARYEN_IGNORE_IMPLICIT_TRAPS¶
是否在 binaryen 中优化时忽略隐式陷阱。隐式陷阱是在超出范围的加载中发生的陷阱，或 0 的除法/取模等。设置此选项后，优化器假定加载不会发生陷阱，因此它们根本没有副作用。这在一般情况下不安全，因为您可能在确保其安全的条件后面有一个加载；但如果加载被假定为没有副作用，它可能会无条件地执行。因此，此选项通常对大型复杂项目没有用，但在足够小的简单代码库中，它可能有助于稍微减小代码大小。
默认值：false
BINARYEN_EXTRA_PASSES¶
要在 binaryen 优化器中运行的额外传递的逗号分隔列表，设置此项不会覆盖/替换默认传递。它被追加到传递列表的末尾。
默认值：“”
WASM_ASYNC_COMPILATION¶
是否异步编译 wasm，这更有效且不会阻塞主线程。目前，除了最小的模块，所有模块都需要在 chrome 中运行。
（此选项以前称为 BINARYEN_ASYNC_COMPILATION）
默认值：true
DYNCALLS¶
如果设置为 1，则 dynCall() 和 dynCall_sig() API 可供调用者使用。
默认值：false
WASM_BIGINT¶
WebAssembly 与 JavaScript BigInt 的集成。启用后，我们不需要将 i64 正规化为 i32 对，因为 wasm VM 将在使用 i64 的地方使用 BigInt。如果存在 WASM_BIGINT，则默认支持的最低浏览器版本将增加到支持 BigInt 的最低版本。
默认值：false
EMIT_PRODUCERS_SECTION¶
WebAssembly 定义了一个“生产者部分”，编译器和工具可以在其中对自身进行注释，LLVM 默认会发出此部分。Emscripten 会将其剥离，因此它不会被发出，因为它会增加代码大小，并且一些用户可能不希望其构建中包含有关其工具的信息，出于隐私或安全原因，请参阅 https://github.com/WebAssembly/tool-conventions/issues/93。
默认值：false
EMIT_EMSCRIPTEN_LICENSE¶
在 JS 输出中发出 emscripten 许可证信息。
默认值：false
LEGALIZE_JS_FFI¶
是否通过包装它们来规范 JS FFI 接口（导入/导出），以自动将 i64 降级为 i32 并将 f32 提升为 f64。这是与 JavaScript 交互所必需的。对于非网络/非 JS 嵌入，将此设置为 0 可能更可取。
注意
此设置已弃用
默认值：true
USE_SDL¶
指定正在链接的 SDL 版本。1 是默认值，是 1.3，在 JS 中实现 2 是 SDL C 代码在 emscripten-ports 上的移植 当 AUTO_JS_LIBRARIES 设置为 0 时，此选项默认为 0，并且 SDL 未链接。使用移植的备用语法：–use-port=sdl2
注意
适用于链接和编译期间
默认值：0
USE_SDL_GFX¶
指定正在链接的 SDL_gfx 版本。必须与 USE_SDL 相匹配
注意
适用于链接和编译期间
默认值：0
USE_SDL_IMAGE¶
指定正在链接的 SDL_image 版本。必须与 USE_SDL 相匹配
注意
适用于链接和编译期间
默认值：1
USE_SDL_TTF¶
指定正在链接的 SDL_ttf 版本。必须与 USE_SDL 相匹配
注意
适用于链接和编译期间
默认值：1
USE_SDL_NET¶
指定正在链接的 SDL_net 版本。必须与 USE_SDL 相匹配
注意
适用于链接和编译期间
默认值：1
USE_ICU¶
1 = 使用来自 emscripten-ports 的 icu 备用语法：–use-port=icu
注意
适用于链接和编译期间
默认值：false
USE_ZLIB¶
1 = 使用来自 emscripten-ports 的 zlib 备用语法：–use-port=zlib
注意
适用于链接和编译期间
默认值：false
USE_BZIP2¶
1 = 使用来自 emscripten-ports 的 bzip2 备用语法：–use-port=bzip2
注意
适用于链接和编译期间
默认值：false
USE_GIFLIB¶
1 = 使用来自 emscripten-ports 的 giflib 备用语法：–use-port=giflib
注意
适用于链接和编译期间
默认值：false
USE_LIBJPEG¶
1 = 使用来自 emscripten-ports 的 libjpeg 备用语法：–use-port=libjpeg
注意
适用于链接和编译期间
默认值：false
USE_LIBPNG¶
1 = 使用来自 emscripten-ports 的 libpng 备用语法：–use-port=libpng
注意
适用于链接和编译期间
默认值：false
USE_REGAL¶
1 = 使用来自 emscripten-ports 的 Regal 备用语法：–use-port=regal
注意
适用于链接和编译期间
默认值：false
USE_BOOST_HEADERS¶
1 = 使用来自 emscripten-ports 的 Boost 头文件 备用语法：–use-port=boost_headers
注意
适用于链接和编译期间
默认值：false
USE_BULLET¶
1 = 使用来自 emscripten-ports 的 bullet 备用语法：–use-port=bullet
注意
适用于链接和编译期间
默认值：false
USE_VORBIS¶
1 = 使用来自 emscripten-ports 的 vorbis 备用语法：–use-port=vorbis
注意
适用于链接和编译期间
默认值：false
USE_OGG¶
1 = 使用来自 emscripten-ports 的 ogg 备用语法：–use-port=ogg
注意
适用于链接和编译期间
默认值：false
USE_MPG123¶
1 = 使用来自 emscripten-ports 的 mpg123 备用语法：–use-port=mpg123
注意
适用于链接和编译期间
默认值：false
USE_FREETYPE¶
1 = 使用来自 emscripten-ports 的 freetype 备用语法：–use-port=freetype
注意
适用于链接和编译期间
默认值：false
USE_SDL_MIXER¶
指定正在链接的 SDL_mixer 版本。不必与 USE_SDL 相匹配，但这是一个好主意。
注意
适用于链接和编译期间
默认值：1
USE_HARFBUZZ¶
1 = 使用来自 harfbuzz 上游的 harfbuzz 备用语法：–use-port=harfbuzz
注意
适用于链接和编译期间
默认值：false
USE_COCOS2D¶
3 = 使用来自 emscripten-ports 的 cocos2d v3 备用语法：–use-port=cocos2d
注意
适用于链接和编译期间
默认值：0
USE_MODPLUG¶
1 = 使用来自 emscripten-ports 的 libmodplug 备用语法：–use-port=libmodplug
注意
适用于链接和编译期间
默认值：false
SDL2_IMAGE_FORMATS¶
在 SDL2_image 中支持的格式。有效值：bmp、gif、lbm、pcx、png、pnm、tga、xcf、xpm、xv
默认值：[]
SDL2_MIXER_FORMATS¶
在 SDL2_mixer 中支持的格式。有效值：ogg、mp3、mod、mid
默认值：[“ogg”]
USE_SQLITE3¶
1 = 使用来自 emscripten-ports 的 sqlite3 备用语法：–use-port=sqlite3
注意
适用于链接和编译期间
默认值：false
WASM_WORKERS¶
如果为 1，则启用对 Wasm 工作器的支持。Wasm 工作器使应用程序能够使用基于 Wasm SharedArrayBuffer + Atomics API 之上的轻量级特定于 Web 的 API 创建线程。启用后，将生成一个新的构建输出文件 a.ww.js 来引导 Wasm 工作器 JS 上下文。如果为 2，则启用对 Wasm 工作器的支持，但不使用单独的 a.ww.js 文件。这可以简化构建的部署，但缺点是生成的构建将不再符合 csp-eval。[编译+链接] - 在编译时影响用户代码，在链接时影响系统库。
默认值：0
AUDIO_WORKLET¶
如果为 true，则启用针对 Wasm Web Audio AudioWorklets 的目标。查看站点/源/文档/api_reference/wasm_audio_worklets.rst 中的完整文档。
默认值：0
WEBAUDIO_DEBUG¶
如果为 true，则启用 Web Audio 后端的深度调试。
默认值：0
PTHREAD_POOL_SIZE¶
在 Web 浏览器中，无法在主浏览器线程执行 JS/Wasm 代码时创建工作器，但主线程必须定期返回到浏览器事件循环才能进行工作器初始化。这意味着从主浏览器线程调用 pthread_create() 本质上是一个异步操作，主线程必须反复返回到 JS 事件循环才能使线程真正开始。如果您的应用程序需要能够同步创建新线程，您可以通过指定 -sPTHREAD_POOL_SIZE=x 预先创建一个 pthread 池，在这种情况下，指定数量的工作器将在应用程序启动之前预先加载到池中，然后可以使用这么多线程进行同步创建。请注意，此设置是一个字符串，并将直接（不带额外引号）在 JS 代码中发出，因此，如果您将其设置为“5”，则池中将使用 5 个工作器，等等。此项设置为字符串的好处是，您可以将其设置为类似“navigator.hardwareConcurrency”的内容（这将使用浏览器报告的内核数量，这将使您的线程池的工作器数量等于内核数量）。[链接] - 在链接时影响生成的 JS 运行时代码
默认值：0
PTHREAD_POOL_SIZE_STRICT¶
通常，即使池为空，应用程序也可以创建新线程。当应用程序在尝试通过 pthread_join 或任何其他阻塞基元阻塞线程之前退出到 JS 事件循环时，将创建一个额外的工作器并执行线程回调。但是，退出到事件循环需要对代码进行自定义修改以使其适应 Web，而并非适用于现成的应用程序。那些没有进行任何修改的应用程序最有可能发生死锁。此设置确保，与其冒死锁风险，不如改为获得运行时 EAGAIN 错误，该错误至少可以从 C/C++ 端优雅地处理。值
0- 禁用线程池耗尽警告1- 启用线程池耗尽警告（默认值）2- 使线程池耗尽成为严重错误
默认值：1
PTHREAD_POOL_DELAY_LOAD¶
如果您的应用程序不需要能够同步创建线程，但它仍然希望通过预热工作器池来适时加快初始线程启动时间，您可以使用 -sPTHREAD_POOL_SIZE=x 指定池的大小，但也可以指定 -sPTHREAD_POOL_DELAY_LOAD，这将导致运行时在启动时不会等待工作器池完成加载。相反，运行时将立即启动，工作器池将在后台异步旋转。这可以缩短 pthread_create() 调用实际启动线程所需的时间，但不会真正减慢主应用程序启动速度。如果 PTHREAD_POOL_DELAY_LOAD=0（默认值），则运行时将在运行 main() 之前等待池启动。如果您确实需要同步等待已创建的线程（例如，通过 pthread_join），则必须在执行此操作之前等待 Module.pthreadPoolReady promise，否则您很可能会遇到死锁。[链接] - 在链接时影响生成的 JS 运行时代码
默认值：false
DEFAULT_PTHREAD_STACK_SIZE¶
为新创建的 pthreads 使用的默认堆栈大小。如果未设置，则默认为 STACK_SIZE（该值又默认为 64k）。也可以使用 pthread_attr_setstacksize() 在运行时设置。请注意，wasm 控制流堆栈与该堆栈是分开的。该堆栈只包含某些函数局部变量，例如那些地址被获取的变量，或者那些太大而无法作为 wasm 代码中的局部变量的变量。
默认值：0
PTHREADS_PROFILING¶
在使用 –threadprofiler 构建时为真。
默认值：false
ALLOW_BLOCKING_ON_MAIN_THREAD¶
在主线程上调用 pthread_join 或 pthread_cond_wait 是危险的，因为这样做会导致 Web 上出现死锁（而且它使用的是繁忙等待，这很昂贵）。请参见 https://emscripten.webassembly.net.cn/docs/porting/pthreads.html#blocking-on-the-main-browser-thread 这将在未来可能默认设置为 0；目前，这只是在控制台中发出警告。
默认值：true
PTHREADS_DEBUG¶
如果为真，则添加调试跟踪以诊断与 pthreads 相关的问题。
默认值：false
EVAL_CTORS¶
这尝试在编译时评估代码。主要的用例是在编译时评估全局构造函数，这些构造函数是在 main() 之前运行的，但 main() 本身或其部分也可以被评估。以这种方式评估代码可以避免在运行时执行工作，因为它将执行结果应用到内存和全局变量等等，对 wasm 进行“快照”，然后在加载时从那里运行。
当它看到一些在编译时无法评估的东西时，例如对导入的调用，它就会停止。在使用此选项运行时，您将看到日志记录，指明评估的内容以及停止的位置。
这种优化既可以减少代码大小，也可以增加代码大小。例如，如果一小段代码会导致内存发生许多更改，那么总体大小可能会增加。
LLVM 的 GlobalOpt 几乎完成了这项操作。它在简单的情况下完成，LLVM IR 对其逻辑来说并不太复杂，但它不足以处理例如 libc++ iostream 构造函数。在 LLVM IR 级别上做到这一点很难 - LLVM IR 很复杂，而且变得越来越复杂，因此这将需要 GlobalOpt 拥有一个完整的解释器，加上一种写回到 LLVM IR 全局对象的方式。然而，在 wasm 级别上，所有东西都被降低到一个简单的低级，我们也只需要将字节写入一个数组，所以这对我们来说很容易做到。LLVM 的另一个问题是，它不知道我们不会链接其他代码，因此它只尝试以最低优先级优化构造函数（而我们明确知道是否启用了动态链接）。
如果设置为 2，这也将做出一些“不安全”的假设，特别是假设在评估构造函数期间没有收到输入。这意味着我们忽略了对 main() 的参数，并且假设环境变量不可读。这允许更多程序进行优化，但您需要确保您的程序不依赖这些功能 - 即使仅仅检查 argc 的值也会导致问题。
默认值：0
TEXTDECODER¶
已启用，使用 JavaScript TextDecoder API 进行字符串封送处理。默认情况下启用，将其设置为 0 以禁用。如果设置为 2，我们假设 TextDecoder 存在且可用，并且不发出任何 JS 代码以在缺少时回退。在单线程 -Oz 构建模式下，TEXTDECODER 默认值为 2 以节省代码大小。
默认值：1
EMBIND_STD_STRING_IS_UTF8¶
Embind 特定：如果启用，则假设 std::string 绑定中的数据使用 UTF-8 编码。禁用它以支持二进制数据传输。
默认值：true
EMBIND_AOT¶
Embind 特定：如果启用，则在编译时生成 Embind 的 JavaScript 调用函数，并将它们包含在 JS 输出文件中。当与 DYNAMIC_EXECUTION=0 一起使用时，这允许导出的绑定与 DYNAMIC_EXECUTION=1 模式一样快，但无需使用 eval()。如果有很多绑定，JS 输出大小可能会更大。
默认值：false
OFFSCREENCANVAS_SUPPORT¶
如果设置为 1，则启用对将画布传输到 pthreads 以及在其中创建 WebGL 上下文的支持，以及对 GL 上下文的显式交换控制。这需要浏览器支持 OffscreenCanvas 规范。
默认值：false
OFFSCREENCANVASES_TO_PTHREAD¶
如果您在使用 PROXY_TO_PTHREAD 时使用 OFFSCREENCANVAS_SUPPORT，则在此指定一个以逗号分隔的 CSS ID 选择器列表，用于将画布代理到程序启动时的 pthread，例如 ‘#canvas1, #canvas2’。
默认值：“#canvas”
OFFSCREEN_FRAMEBUFFER¶
如果设置为 1，则启用对 WebGL 上下文渲染到离屏渲染目标的支持，以避免 WebGL 的隐式交换行为，其中退出任何事件回调都会自动执行“翻转”以将渲染的内容呈现到屏幕上。当 Emscripten GL 上下文启用离屏帧缓冲区时，单个帧可以从多个事件回调中合成，然后显式调用 swap 函数 emscripten_webgl_commit_frame() 以将渲染的内容呈现到屏幕上。
OffscreenCanvas 功能还启用了显式 GL 帧交换支持，此外，-sOFFSCREEN_FRAMEBUFFER 功能可用于模拟在浏览器不支持 OffscreenCanvas 的情况下访问多个线程中的 WebGL，但会损失一些性能和延迟。OffscreenCanvas 和离屏帧缓冲区支持可以同时启用，允许您在可用时使用 OffscreenCanvas，并在其他情况下回退到离屏帧缓冲区。
默认值：false
FETCH_SUPPORT_INDEXEDDB¶
如果非零，Fetch API 支持备份到 IndexedDB。如果为 0，则不使用 IndexedDB。如果目标应用程序不感兴趣，请将其设置为 0，以节省几 KB。
默认值：true
FETCH_DEBUG¶
如果非零，则在 library_fetch.js 中打印调试信息。
默认值：false
FETCH¶
如果非零，则启用 emscripten_fetch API。
默认值：false
WASMFS¶
注意 [WIP]：实验性功能。请自行承担风险使用。这将最终替换当前的 JS 文件系统实现。如果设置为 1，则使用新的文件系统实现。
注意
这是一个实验性设置
默认值：false
SINGLE_FILE¶
如果设置为 1，则将所有子资源嵌入到作为 base64 字符串文字发出的文件中。嵌入的子资源可能包括（但不限于）wasm、asm.js 和静态内存初始化代码。
当使用依赖此选项的代码时，您可能需要更新您的内容安全策略。具体来说，嵌入 asm.js 需要 script-src 指令允许 'unsafe-inline'，使用 Worker 需要 child-src 指令允许 blob:。如果您没有使用内容安全策略，或者您的 CSP 标头不包含 script-src 或 child-src，那么您可以安全地忽略此警告。
默认值：false
AUTO_JS_LIBRARIES¶
如果设置为 1，则所有 JS 库将在链接时自动可用。这在 STRICT 模式（或使用 MINIMAL_RUNTIME）中设置为 0，这意味着您需要在链接时显式指定 -lfoo.js 才能访问 library_foo.js 中的库函数。
默认值：true
AUTO_NATIVE_LIBRARIES¶
与 AUTO_JS_LIBRARIES 相似，但用于原生库，例如 libgl、libal 和 libhtml5。如果禁用了此选项，则需要显式添加例如 -lhtml5，并且还要先使用 embuilder 构建库。
默认值：true
MIN_FIREFOX_VERSION¶
指定要定位的最旧的 Firefox 主版本。也就是说，所有 Firefox 版本 >= MIN_FIREFOX_VERSION 都希望工作。传递 -sMIN_FIREFOX_VERSION=majorVersion 以放弃对 Firefox 版本的旧版本的支持 < majorVersion。Firefox 79 于 2020 年 7 月 28 日发布。MAX_INT (0x7FFFFFFF，或 -1) 指定不支持该目标。最小支持值为 34，该值于 2014 年 12 月 1 日发布。
默认值：79
MIN_SAFARI_VERSION¶
指定要定位的最旧的桌面 Safari 版本。版本以 MMmmVV 编码，例如 70101 表示 Safari 7.1.1。Safari 14.1.0 于 2021 年 4 月 26 日发布，与 macOS 11.0 Big Sur 和 iOS 14.5 捆绑在一起。之前的默认值 Safari 12.0.0 于 2018 年 9 月 17 日发布，与 macOS 10.14.0 Mojave 捆绑在一起。注意：Emscripten 无法生成在 iOS 9.3.5 和更旧版本中工作的代码，即 iPhone 4s、iPad 2、iPad 3、iPad Mini 1、Pod Touch 5 和更旧版本，请参见 https://github.com/emscripten-core/emscripten/pull/7191。MAX_INT (0x7FFFFFFF，或 -1) 指定不支持该目标。最小支持值为 90000，该值于 2015 年发布。
默认值：140100
MIN_CHROME_VERSION¶
指定最旧的 Chrome 版本。例如，传递 -sMIN_CHROME_VERSION=58 以放弃对 Chrome 57 和更旧版本的支持。此设置也适用于基于 Chromium 的现代 Edge，它与 Chrome 共享版本号。Chrome 85 于 2020 年 8 月 25 日发布。MAX_INT (0x7FFFFFFF，或 -1) 指定不支持该目标。最小支持值为 32，该值于 2014 年 1 月 4 日发布。
默认值：85
MIN_NODE_VERSION¶
指定为生成的代码定位的最小 Node 版本。这与运行 emscripten 编译器所需的最小版本不同。此版本与当前的 Ubuuntu TLS 20.04 (Focal) 一致。版本以 MMmmVV 编码，例如 181401 表示 Node 18.14.01。最小支持值为 101900，该值于 2020 年 2 月 5 日发布。
默认值：160000
SUPPORT_ERRNO¶
我们是否支持从 JS 库代码设置 errno。在 MINIMAL_RUNTIME 构建中，此选项默认为 0。
注意
此设置已弃用
默认值：true
MINIMAL_RUNTIME¶
如果为真，则使用没有 POSIX 功能、Module、preRun/preInit 等、Emscripten 内置 XHR 加载或 library_browser.js 的最小大小运行时。启用此设置以定位最小的代码大小。将 MINIMAL_RUNTIME 设置为 2 以进一步启用更多代码大小优化。这些选项非常 hacky，并且解决了 Closure 和构建系统其他部分的限制，因此它们可能无法在所有生成的程序中工作（但对于非常小的程序可能很有用）。
默认情况下，Module 对象上不会导出任何符号。为了导出保持活动状态的符号，请使用 -sEXPORT_KEEPALIVE=1。
默认值：0
MINIMAL_RUNTIME_STREAMING_WASM_COMPILATION¶
如果设置为 1，MINIMAL_RUNTIME 将使用流式 WebAssembly 编译，其中 WebAssembly 模块将在下载时进行编译。为了使此功能正常工作，Web 服务器必须使用 HTTP 响应头“Content-Type: application/wasm”正确地提供 .wasm 文件。如果此 HTTP 头不存在，例如 Firefox 73 将出现错误消息 TypeError: Response has unsupported MIME type，而 Chrome 78 将出现错误消息 Uncaught (in promise) TypeError: Failed to execute ‘compile’ on ‘WebAssembly’: Incorrect response MIME type. Expected ‘application/wasm’。如果设置为 0（默认值），则流式 WebAssembly 编译将被禁用，这意味着 WebAssembly 模块将首先完全下载，然后才开始编译。对于大型 .wasm 模块和生产环境，应将其设置为 1 以加快启动速度。但是此设置默认情况下处于禁用状态，因为它需要服务器端配置，并且对于非常小的页面，没有观察到任何差异（也会对代码大小造成约 100 字节的影响）。
默认值：false
MINIMAL_RUNTIME_STREAMING_WASM_INSTANTIATION¶
如果设置为 1，MINIMAL_RUNTIME 将使用流式 WebAssembly 实例化，其中 WebAssembly 模块将在下载时进行编译+实例化。与 MINIMAL_RUNTIME_STREAMING_WASM_COMPILATION 相同的限制/要求适用。MINIMAL_RUNTIME_STREAMING_WASM_COMPILATION 和 MINIMAL_RUNTIME_STREAMING_WASM_INSTANTIATION 不能同时处于活动状态。哪一个更快取决于 wasm 模块的大小、JS 运行时文件的大小、要下载的预加载数据文件的大小以及所讨论的浏览器。
默认值：false
SUPPORT_LONGJMP¶
如果设置为“emscripten”或“wasm”，编译器支持 setjmp() 和 longjmp()。如果设置为 0，则这些 API 不可用。如果您使用的是 C++ 异常，但不需要 setjmp()+longjmp() API，则可以将其设置为 0，以便在捕获异常时节省一些代码大小和性能。
‘emscripten’: (默认) Emscripten 使用 JavaScript 处理 setjmp/longjmp ‘wasm’: 使用 Wasm EH 指令处理 setjmp/longjmp（实验性）
0: 无 setjmp/longjmp 处理
1: 默认 setjmp/longjmp/处理，取决于异常模式。如果使用“-fwasm-exception”，则为“wasm”，否则为“emscripten”。
[编译+链接] - 在编译时，这将启用在代码生成时进行 longjmp 支持所需的转换，而在链接时，它允许链接到库支持。
默认值：true
DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR¶
如果设置为 1，则禁用旧的已弃用的 HTML5 API 事件目标查找行为。启用后，将不存在“Module.canvas”对象，没有神奇的“null”默认处理，并且 DOM 元素“target”参数被视为引用 CSS 选择器，而不是引用 DOM ID。
默认值：true
HTML5_SUPPORT_DEFERRING_USER_SENSITIVE_REQUESTS¶
某些浏览器 DOM API 操作，例如请求全屏模式转换或指针锁定，要求请求源自用户发起的事件，例如鼠标点击或键盘按下。将应用程序重构为遵循这种程序结构可能很困难，因此 HTML5_SUPPORT_DEFERRING_USER_SENSITIVE_REQUESTS 允许通过延迟此类请求直到生成合适的事件回调来透明地模拟这一点。将其设置为 0 以禁用对延迟的支持，以便在应用程序不需要对延迟调用支持的情况下节省代码大小。
默认值：true
MINIFY_HTML¶
指定生成的 .html 文件是否通过 html-minifier 运行。html-minifier 运行的优化传递集取决于调试和优化级别。在 -g2 及更高版本中，不执行任何缩小操作。在 -g1 中，会执行缩小操作，但会保留空格。缩小需要使用至少 -O1 或 -Os。传递 -sMINIFY_HTML=0 以明确选择完全禁用 HTML 缩小操作。
默认值：true
MAYBE_WASM2JS¶
我们可能使用 wasm2js。这通常会编译成 wasm，但允许您稍后在 wasm 上运行 wasm2js，并且您可以选择在正常 wasm 或 wasm2js 代码之间运行。有关如何执行此操作的详细信息，请参见 test_maybe_wasm2js 测试。此选项对于调试和二分搜索很有用。
默认值：false
ASAN_SHADOW_SIZE¶
此选项不再使用。现在根据 INITIAL_MEMORY 和 MAXIMUM_MEMORY 计算适当的阴影内存大小。将在未来版本中删除。
默认值：-1
USE_OFFSET_CONVERTER¶
我们是否应该使用偏移量转换器。这对于较旧版本的 v8（<7.7）是必需的，因为较旧版本的 v8 不会在堆栈跟踪中给出 wasm 二进制文件中的十六进制模块偏移量，以及用于避免跨函数边界的源映射条目。
默认值：false
LOAD_SOURCE_MAP¶
我们是否应该在运行时加载 WASM 源映射。当使用 -gsource-map 与消毒剂一起使用时，将自动启用此功能。
默认值：false
DEFAULT_TO_CXX¶
即使以 emcc 而不是 emc++ 的形式运行，也默认使用 c++ 模式。禁用此选项后，需要 em++ 来链接 C++ 程序。禁用此选项将与 gcc/g++ 和 clang/clang++ 的行为相匹配。
默认值：true
PRINTF_LONG_DOUBLE¶
虽然 LLVM 的 wasm32 有 long double = float128，但我们默认情况下不支持以完全精度打印它。相反，我们打印为 64 位双精度数，这可以节省 libc 代码大小。您可以将此选项打开以获得具有完全 long double 打印精度的 libc。
默认值：false
SEPARATE_DWARF_URL¶
设置此选项会影响在 wasm 中发出的引用 DWARF 文件的路径，在 -gseparate-dwarf 模式下。这允许调试文件托管在自定义位置。
默认值：‘’
ERROR_ON_WASM_CHANGES_AFTER_LINK¶
Emscripten 运行 wasm-ld 进行链接，并且在某些情况下会在之后对 wasm 进行进一步更改，例如运行 wasm-opt 以在优化构建中优化二进制文件。但是，在某些构建中，链接后不需要对 wasm 进行任何更改。这可以使整个链接步骤更快，并且由于其他原因也很重要，例如在调试中，如果 wasm 未修改，则 LLVM 中的 DWARF 信息将被保留（wasm-opt 在某些情况下可以重写它，但在其他情况下则不能，例如 split-dwarf）。当此标志被打开时，如果构建在链接后需要对 wasm 进行任何更改，我们会在链接时出错。这在测试中可能很有用，例如。需要链接后 wasm 更改的某些功能示例是：- 将 i64 下降到 JS 边界处的 i32 对（参见 WASM_BIGINT）- 在针对较旧的浏览器时降低符号扩展操作。
默认值：false
ABORT_ON_WASM_EXCEPTIONS¶
在调用导出的 WebAssembly 函数时发生的未捕获异常时中止。这使得程序的行为更像一个本机程序，其中操作系统会终止进程，并且在发生未捕获异常（例如内存访问越界）时无法执行任何其他代码。这将为所有导出函数添加工具，以捕获抛出的异常，并在发生异常时调用 abort()。程序中止后，任何导出函数调用都将失败，并出现“程序已中止”异常，以防止调用具有潜在损坏程序状态的代码。这在优化构建中对代码大小添加了一个小的固定数量，并且为额外的工具函数间接调用添加了一点开销。如果您希望 Emscripten 以额外的字节为代价很好地处理未捕获的异常，请启用此选项。在 main 函数中发生的异常已经通过替代机制进行处理。
默认值：false
PURE_WASI¶
构建使用尽可能多的 WASI API 的二进制文件，并为这些 API 包含额外的 JS 支持库。这允许 emscripten 生成二进制文件，这些二进制文件更符合 WASI 标准，并且还允许它处理和执行使用其他 SDK（例如 wasi-sdk）构建的 WASI 二进制文件。此设置是实验性的，可能会更改或删除。这意味着 STANDALONE_WASM。
注意
这是一个实验性设置
默认值：false
IMPORTED_MEMORY¶
设置为 1 以在 wasm 模块外部定义 WebAssembly.Memory 对象。默认情况下，wasm 模块定义内存并将其导出到 JavaScript。使用以下设置将启用此设置，因为它们依赖于能够在 JavaScript 中定义内存：- -pthread - RELOCATABLE - ASYNCIFY_LAZY_LOAD_CODE - WASM2JS (WASM=0)
默认值：false
SPLIT_MODULE¶
生成代码以加载拆分的 wasm 模块。此选项将自动生成两个 wasm 文件作为输出，一个带有 .orig 后缀，另一个没有。默认文件（没有后缀）在运行时将生成工具数据，这些数据稍后可以输入 wasm-split（binaryen 工具）。除了这一点之外，生成的 JS 代码还将包含用于加载拆分模块的帮助函数。
默认值：false
AUTOLOAD_DYLIBS¶
对于 MAIN_MODULE 构建，在启动时自动加载任何动态库依赖项，然后再加载主模块。
默认值：true
ALLOW_UNIMPLEMENTED_SYSCALLS¶
包括未实现的 JS 系统调用以包含在最终输出中。这允许依赖这些系统调用的程序在运行时进行编译，即使这些系统调用在运行时会失败（或不执行任何操作）。
默认值：true
TRUSTED_TYPES¶
允许调用 Worker(…) 和 importScripts(…) 成为可信类型兼容。可信类型是 Web 平台功能，旨在通过限制 DOM 接收器 API 的使用来缓解 DOM XSS。参见 https://w3c.github.io/webappsec-trusted-types/.
默认值：false
POLYFILL¶
在针对较旧的浏览器时，emscripten 有时需要在输出中包含 polyfill。如果您希望通过其他机制自己进行 polyfill，则可以通过传递 -sNO_POLYFILL 或 -sPOLYFILL=0 来阻止 emscripten 生成这些 polyfill。使用默认的浏览器目标，emscripten 不需要任何 polyfill，因此此设置仅在显式地也针对较旧的浏览器时才需要。
默认值：true
RUNTIME_DEBUG¶
如果为真，则将跟踪添加到核心运行时函数中。如果启用了以下任何调试设置，则默认情况下会启用此设置：- PTHREADS_DEBUG - DYLINK_DEBUG - LIBRARY_DEBUG - GL_DEBUG - OPENAL_DEBUG - EXCEPTION_DEBUG - SYSCALL_DEBUG - WEBSOCKET_DEBUG - SOCKET_DEBUG - FETCH_DEBUG
默认值：false
旧版运行时¶
包含以前是默认运行时一部分的 JS 库符号。没有它，可以通过将这些符号添加到 DEFAULT_LIBRARY_FUNCS_TO_INCLUDE，或者通过另一个 JS 库符号的依赖关系来使这些符号可用。
默认值：false
签名转换¶
用户定义的函数，用于用签名转换包装，这些函数接受或返回指针参数。仅影响 MEMORY64=1 构建，有关详细信息，请参见 emscripten.py 中的 create_pointer_conversion_wrappers。使用 _ 表示非指针参数，p 表示指针/i53 参数，P 表示可选指针/i53 值。示例使用 -sSIGNATURE_CONVERSIONS=someFunction:_p,anotherFunction:p
默认值：[]