01 / DOWNLOAD & ASSETS
Mihomo内核下载、GitHub发布文件及系统架构选择指南
把操作系统、CPU架构与构建要求一一对应,再获取适合目标设备的二进制程序。版本号和资源清单以实际发布为准。

先记下系统与CPU架构
AMD64常见于x86-64的Intel与AMD处理器;ARM64则用于相应的64位ARM环境。386是32位x86构建标记。架构相同,也要继续核对系统版本和CPU指令集要求;并非每一个Release都包含表中全部组合。
| 运行平台 | 常见名称线索 | 选择时继续核对 |
|---|---|---|
| Windows | windows / amd64、arm64、386 | 系统类型、CPU架构与构建要求;解压后的可执行文件。 |
| Linux | linux / amd64、arm64等 | 机器架构、系统内核要求;压缩二进制或DEB/RPM等适配包。 |
| macOS | darwin / amd64、arm64 | Intel与Apple Silicon架构;所选构建的系统兼容说明。 |
| 其他架构 | arm32v7、riscv64等实际发布标记 | 以该次发布资源为准,不将其他架构文件改名后使用。 |
Windows可从系统信息读取架构,Linux与macOS可用uname -m查询。兼容层、虚拟机和容器应按真正运行核心的环境选择。完整方法见GitHub发布文件识别笔记。
文件名中,哪些标记不能跳过?
mihomo-<系统>-<架构>-<构建标记>-<版本>.<压缩格式>这是一种示意结构,具体字段、顺序与扩展名依实际资源而异。AMD64的v1/v2/v3表示CPU指令集等级,不是内核主版本。带go版本标记的构建可能为特定兼容需求提供。若旧硬件运行时提示非法指令,应核对构建等级,而不是改文件名重试。
ZIP、GZ和发行版软件包采用不同处理方式。GZ通常压缩一个文件,解压后还需要核对执行权限。先保留原文件名与下载记录,再按安装部署指南进入首次运行。
用变更说明选择版本渠道
GitHub Releases中的Release可作为常规评估起点;Alpha更适合跟进较新的提交、验证修复或特定功能。两者都需要结合已知问题与使用环境判断,不能简单等同于绝对稳定和绝对不稳定。
寻找Mihomo最新版时,先确认发布标记、资源名称、系统要求与配置兼容性。这里不固定展示可能过期的“最新版本号”,也不把新的构建自动视为适合现有部署。
下载之后,先检查再执行
确认压缩包完整、可以解压,按可信发布记录核对校验值;若只有自己计算的散列,它只能标识文件,不能独立证明来源。记录版本和原始包名,便于以后定位问题。
按平台继续阅读:Windows解压后的运行方法说明终端执行与配置路径;Linux进程与服务管理说明执行权限、账户和日志。二进制文件能启动,也不意味着已经配置好连接。


