Merged
feat(npm): support OpenHarmony arm64 via the static Linux binary #515
YodonTanAdd on Aug 27
feat(npm): support OpenHarmony arm64 via the static Linux binary #515
Merged
Merged fromYodonTan/clifeature/openharmony-arm64-npmintoatomgit-cli/climain
Pull Request has been successfully merged by aflyingto.
（Thank you for YodonTan's contribution.）
٩(ˊvˋ*)و。。。
Sep 16 Comments：
Sep 16 Comments：
评审反馈：P1–P4（Approve with minor comments）
对本 PR 做了代码 / 安全 / 测试 / 文档四个维度的评审，核心机制（openharmony → linux 别名映射 + 随包分发的静态 arm64 二进制）成立，整体 Approve with minor comments。以下 4 项均不阻塞合并，建议合并前优先处理 P1。
P1（minor）openharmony/x64 隐式支持但未声明 —— 行为与声明不一致
npm/lib/platform.js的PLATFORM_MAP中openharmony: "linux"是平台级别名、与 arch 无关：resolveBinaryName("openharmony", "x64")会返回gc-linux-amd64，isSupported("openharmony", "x64")返回true- 但 L38 错误信息的 supported 列表与文档均只声明
openharmony/arm64 - 且现实中 OpenHarmony 标准系统目前仅有 arm64 形态，无 x86_64 官方运行环境
- 建议：收窄映射为仅 arm64（消除声明外的隐式行为），或在错误信息/文档如实声明 x64；无论哪种，建议补
openharmony/x64测试用例钉住意图
P2（low）platform.js 头注释语义漂移
- L2–5 注释声称 "Mirrors the selection logic in gc_cli/wrapper.py (get_binary_name)"
- 但 Python 侧基于
uname做运行时判断，OpenHarmony 上uname报 Linux、天然命中 linux 分支，无需别名——"镜像"关系不成立，易误导后续维护，建议更新措辞
P3（minor）文档同步遗漏
- PR 只更新了
docs/INTRODUCTION.md，同构的环境枚举句还有两处副本未提 OpenHarmony：- 根
README.mdL41（"Windows、Linux、macOS 与 AI 环境"） docs/AI-GUIDE.mdL13（同构句）
- 根
- 建议一并同步
P4（minor）PR body 流程问题
- PR body 含裸 issue 引用（58350，裸
#NNN形式）且无Closes/Refs关联 - 按
AGENTS.md§9，GitCode 上裸 issue 引用存在误关闭风险，建议改为明确的Closes/Refs或移除
附：功能验证说明
在 arm64 环境（ubuntu-24.04-arm）对 f675f1c 做了五层验证，全部通过：
- L1：
npm/test/platform.test.js5/5 通过（含 openharmony alias 断言） - L2/L2b：静态二进制与 npm wrapper 在 musl（alpine）用户态运行正常，wrapper 按 openharmony 平台正确解析到
gc-linux-arm64 - L3：真实 OpenHarmony 7.0 用户态容器（dockerharmony，rootfs 取自官方 v7.0 rk3568 构建产物）：
gc-linux-arm64 version/--help正常 - L3b：真 OpenHarmony Node（ohos-node，
process.platform原生为openharmony）端到端运行未修改的 npm wrapper：查表解析 → execgc-linux-arm64→ 输出正常
静态构建（全链路 CGO_ENABLED=0）是上述兼容性的前提，未发现回归。
背景
在 OpenHarmony 设备的 npm/npx 环境中运行
npx @gitcode-cli/cli会失败：OpenHarmony 标准系统上的 Node.js 构建（官方上游已支持，见 nodejs/node BUILDING.md）报告的process.platform === "openharmony"，而现有 npm 平台解析器只识别 linux/darwin/win32，直接抛出unsupported platform/arch: openharmony/arm64，无法提供 gc 二进制。方案
复用现有
gc-linux-arm64发行资产：CGO_ENABLED=0纯静态构建，不依赖用户态 libc，可在该内核上直接运行；openharmony映射到linux，与 Node.js 对 Android 复用 Linux 用户态的路线一致，无需新增构建目标或发行产物。改动
npm/lib/platform.js：PLATFORM_MAP增加openharmony -> linux别名，更新支持列表提示npm/test/platform.test.js：新增 openharmony/arm64 映射、isSupported 与别名用例npm/README.md：Supported platforms 增加 OpenHarmony arm64 及说明docs/INTRODUCTION.md：渠道与平台支持说明同步更新验证
process.platform="openharmony",process.arch="arm64"）上实测，resolveBinaryName正确返回gc-linux-arm64，isSupported为 truenpm test59/60 通过；唯一失败为chooseGlobalBinDir在设备/tmp上的 mkdir ENOENT，属于环境限制（基线代码同样失败，与本次改动无关）影响面
不改变现有平台的二进制选择；不新增构建目标；OpenHarmony 用户可直接复用现有 linux/arm64 发行文件。