企业官网建设流程全解析

scriptc平台支持矩阵全解析：macOS、Linux、Windows、iOS、Android与WASI指南

【免费下载链接】scriptcTypeScript-to-Native Compiler项目地址: https://gitcode.com/GitHub_Trending/sc/scriptc

scriptc 是一个 TypeScript-to-Native 编译器，能把 TypeScript/JavaScript 直接编译成原生可执行文件、静态库和 WebAssembly 模块，编译产物无需 Node.js 即可运行。本文将完整解析scriptc 平台支持矩阵：macOS、Linux、Windows 三大桌面/服务器平台如何作为宿主编译，iOS 与 Android 如何通过库模式接入 App，以及 WASI（WebAssembly）目标的能力边界，帮助你在 10 分钟内搞清每个平台"能编译什么、需要什么工具链"。

一、scriptc 是什么？为什么需要平台支持矩阵

一句话概括：你写普通的 TypeScript，scriptc 把它变成不依赖 Node 的原生二进制——启动更快、部署更简单，产物里没有 JS 引擎，只有一小段内置的 C 运行时（源码位于 packages/runtime/src）。

理解平台矩阵的关键，是先理解 scriptc 的两条编译路线：

所有平台的底层能力清单，可以对照官方文档 docs/src/app/platforms/page.mdx 查看；快速上手请看 docs/src/app/quickstart/page.mdx。

二、总览：scriptc 平台支持矩阵一览表

💡 规律总结：桌面平台做可执行文件，移动平台做静态库，WASI 做可移植模块。

三、macOS：首选宿主平台，体验最完整

macOS 是 scriptc 的主要开发平台，arm64 与 x64 均受支持：

• 安装要求：Node.js ≥ 24；可执行文件构建需要 clang（Xcode Command Line Tools 自带）。
• 无需编译 C：在 macOS 15+ arm64 上，普通可执行文件构建使用 scriptc 自带的 helper 与预编译运行时包，clang 只充当链接器驱动，不会去编译你程序或运行时的 C 代码。
• 产物细节：汇编/对象产物标注arm64-apple-macosx14.0.0部署目标；sanitizer 构建走外部 C 路线。
• npm 包支持：--dynamic会把依赖的 JS 嵌入二进制，运行时不读node_modules。

macOS 上的调试也很方便：--optimization=dev构建支持源码断点与原生堆栈帧，调试符号存放在相邻的.dSYM包中（详见 docs/src/app/limitations/page.mdx 的"Native debugging"一节）。

四、Linux：glibc 与 musl 全覆盖，服务器场景友好

Linux 是另一个一等公民平台，x86_64 与 arm64 都支持，且分两种 libc：

• glibc 目标：默认路线，链接可执行文件需匹配的 glibc/sysroot。
• musl 目标（Alpine 容器友好）：设置SCRIPTC_TARGET=<arch>-linux-musl后，zig 会产出静态链接的可执行文件，非常适合极简容器部署。

运行时有完整的 Linux 原生后端：事件循环用epoll、服务器栈、TLS（含发行版 CA bundle 探测）、fs.watch都有 Linux 实现，并通过容器化差分测试对照 Linux Node 逐字节验证。

交叉编译示例（在 macOS 上构建 Linux 二进制）：

SCRIPTC_CC=zigcc SCRIPTC_TARGET=x86_64-linux-gnu.2.36 scriptc build fib.ts -o fib-linux # 产物：ELF 64-bit x86-64 可执行文件

五、Windows：x86_64 MSVC 路线，含 GUI 子系统选项

Windows x86_64 受支持，使用原生 MSVC helper + 运行时包：

• 静态与动态面均可用：网络服务器、TLS、原生fetch（含重定向、流式响应、压缩、代理）、child_process等。
• GUI 应用技巧：默认构建使用控制台子系统；如果你的程序自己创建窗口，加--windows-subsystem=gui可避免弹出多余的黑色控制台窗口。
• 交叉编译（从 macOS 构建）：

SCRIPTC_CC=zigcc SCRIPTC_TARGET=x86_64-windows-gnu scriptc build fib.ts -o fib.exe # 产物：PE32+ executable (console) x86-64

Windows 测试通道会跑完整测试语料，包括真实的回环网络流量（net、http、https、tls、http2、dgram、dns）。

六、iOS 与 Android：库模式，为 App 而生

⚠️ 这是新手最容易误解的部分：移动端不做可执行文件。移动 App 本身就是可执行体，所以 scriptc 为 iOS/Android 提供的是库模式静态归档，由你的 App 项目链接。直接scriptc build不加--lib会得到SC3002诊断——这是设计使然，不是故障。

库模式的完整能力可用：profile 声明的导出与 ABI 入口点、宿主回调通道、多实例归档（abi.localize_runtime）、线程实例化状态（abi.instance_per_thread）。模拟器/仿真器上还有真实执行的测试矩阵，真机架构的归档经过构建与链接验证。

# iOS（macOS 主机） SCRIPTC_CC=zigcc SCRIPTC_TARGET=aarch64-apple-ios scriptc build --lib --profile app.profile.json # Android（任意主机 + NDK） SCRIPTC_CC=zigcc SCRIPTC_TARGET=aarch64-linux-android scriptc build --lib --profile app.profile.json

七、WASI（WebAssembly）：可移植性最强的目标

设置SCRIPTC_CC=zigcc与SCRIPTC_TARGET=wasm32-wasi，即可产出独立的.wasm模块，可运行在任意WASI Preview 1 宿主中，不止 Node：

SCRIPTC_CC=zigcc SCRIPTC_TARGET=wasm32-wasi scriptc run hello.ts # hello, world —— 由 Node 的 WASI 实现托管执行

• 语言层级完整：async/await、Promise、生成器、定时器、stdin/readline 事件、文件系统的回调与 Promise、--dynamicQuickJS 岛屿，全部可用。
• 边界是宿主能力，不是语言能力：WASI Preview 1 没有可移植的 socket、进程派生、OS 信号、网络接口、文件系统通知 API，所以 networking/fetch、子进程、信号 API、fs.watch会在链接前以SC3002明确报错。
• scriptc run执行 .wasm 时会继承 stdio 与环境变量，把当前工作目录预打开为/，并把宿主临时目录映射到/tmp。

八、交叉编译怎么配？两个环境变量就够

所有交叉目标（Linux、Windows、iOS、Android、WASI）都通过 zig 完成，只需设置两个环境变量：

需要先在PATH中安装zig。注意：--sanitize是宿主构建路线，交叉目标不可用；移动端仅支持库模式可接受的语言面（无 async 的静态层级）。

九、常见限制：选平台前先读这里 📋

来自 docs/src/app/limitations/page.mdx：

• --sanitize、原生 FFI、--lib归档：WASI 均不可用；
• 移动端仅库模式：单独的可执行构建会以SC3002拒绝；
• iOS 只能在 macOS 主机上构建（Apple SDK sysroot 限制）；Android 可在任意有 NDK 的主机构建；
• WASI 文件系统访问受宿主 preopens 约束，进程/OS 自省遵循 WASI 的精简模型；
• 编译产物不内嵌 N-API/V8 插件运行时，原生插件请走 docs/src/app/ffi/page.mdx 描述的 C ABI FFI 路线。

十、资源索引：关键文件路径

结语：scriptc 的平台矩阵设计逻辑非常清晰——桌面三平台追求"零依赖可执行文件"，移动端以"静态库嵌入 App"的方式参与，WASI 提供最强的跨宿主可移植性。无论你是部署 CLI 工具、API 服务器还是移动 App 内的 TypeScript 逻辑，都能在上面找到对应路线。下一步建议：先在你的宿主机上跑一遍scriptc coverage，用带编码的诊断报告确认你的程序能静态编译到什么程度。

【免费下载链接】scriptcTypeScript-to-Native Compiler项目地址: https://gitcode.com/GitHub_Trending/sc/scriptc