wrt_release：多设备 OpenWrt 固件一键构建脚本

获取下载链全程约 1 分钟

打开微信，搜索「软件教程管家」关注，或长按下方二维码关注
回复关键词 wrt-release
公众号自动回复网盘链接，点击即可保存下载

打开微信扫一扫关注
或搜索【软件教程管家】

wrt_release 是一套面向多设备 OpenWrt 固件构建的自动化脚本，解决的是重复编译定制固件的脏活：拉源码、合配置、打补丁、调 feeds、收固件，全套流程用脚本编排起来。它覆盖 OpenWrt、ImmortalWrt 与 LiBwrt 三条上游，支持本机、Docker 和 GitHub Actions 三种构建方式，适合需要长期给一批路由器或 x86 设备出定制固件的人，而不是只编译一次尝鲜的用户。

基本信息

项目	内容
项目名称	wrt_release
仓库地址	github.com/ZqinKing/wrt_release
Stars	718
上游源码	OpenWrt、ImmortalWrt、LiBwrt
构建方式	本机构建、Docker 构建、GitHub Actions 构建
配置方式	设备 .ini、.config 与可组合 fragments
运行环境	Ubuntu LTS 或其他主流 Linux 发行版
输出位置	仓库根目录的 firmware 目录

快速判断

如果目标是为 README 已列出的路由器或 x86 平台持续生成定制固件，这个项目可以作为设备配置和构建流程的自动化入口。它更适合熟悉 OpenWrt 配置、Shell、Linux 编译环境和固件刷写风险的用户；若需要未列出的设备、完全隔离的供应链或明确的长期维护承诺，应先审查源码和配置，不能仅依据仓库摘要作出判断。

核心功能

自动拉取源码并完整编译：项目可根据设备配置自动拉取 OpenWrt、ImmortalWrt 或 LiBwrt 源码并执行完整编译，不用手工一步步跟构建流程。
设备配置分离管理：项目通过设备 .ini、.config 和可组合 fragments 管理目标平台、软件包与默认构建选项，多设备共用一套骨架。
多种构建流程：支持直接构建、debug、配置预览、Docker 构建和容器调试等多种流程，本机和容器都能跑。
update.sh 统一编排：项目能够通过 update.sh 编排源码准备、feeds 调整、软件包同步和补丁应用，构建前的准备动作收进一个入口。
固件自动归集：项目会将完整构建得到的固件从目标目录收集到仓库根目录的 firmware 目录，构建完直接去固定位置取。
多平台覆盖：已支持的设备包括京东云、阿里云、Linksys、红米、兆能、Nokia、x86 等，同一套脚本服务多类目标。
构建前可预检：提供 debug 与 config_preview 模式，便于在完整编译前检查配置组合，少烧几轮编译时间。

版本选择

wrt_release 的版本选择分三层，都要对齐。第一层是上游源码：OpenWrt、ImmortalWrt、LiBwrt 三选一，按设备 .ini 里写明的仓库、分支来，不要跨上游混配。第二层是设备配置：只选仓库 compilecfg 与 deconfig 里已有的设备，未列出的设备没有现成配置可抄。第三层是构建方式：本机直建最直接，Docker 构建能减少部分本地环境差异，GitHub Actions 适合不想占用本机构建资源的场景。三层定完再动手，边改边试最容易把配置搅乱。

安装步骤

准备一台 Ubuntu LTS 或其他主流 Linux 发行版机器，留足磁盘空间和内存，并确认文件系统对大小写敏感。
拉取 wrt_release 仓库，找到目标设备对应的 .ini 与 .config 文件，先通读再改。
确认设备 .ini 里的上游仓库、分支、可选提交哈希、构建目录和 SDK 镜像是否符合预期。
用 update.sh 编排源码准备、feeds 调整、软件包同步和补丁应用，完成构建前的准备。
先用 debug 检查配置，再用 config_preview 预览 fragments 的组合结果，确认无误再进完整编译。
执行构建，完成后到仓库根目录的 firmware 目录取固件，并及时归档需要保留的输出。

必改设置

设备 .ini 的上游指向：每个设备的上游仓库、分支、可选提交哈希、构建目录和 SDK 镜像都要逐项核对，抄错一个分支，编出来的固件就不是你要的那套。
fragments 组合：按需组合配置片段，例如代理、NSS、Docker 依赖等，只加本次构建真正需要的片段，多余片段会拖慢编译、增加出问题的面。
feeds 与补丁：三方插件主要通过 feeds 机制加入，补丁内容要在构建前确认，升级上游源码或 feeds 之前先用 debug 或 config_preview 检查配置变化。
构建方式二选一：本机直建和 Docker 构建不要混着来，选容器模式要先确认 Docker 能正常运行，选本机模式要先确认编译依赖齐全。
输出归档习惯：完整构建会清理旧目标固件文件并移除 firmware 目录下的 Packages.manifest，重要固件构建完立刻归档，不要留在输出目录里等下一轮构建。

注意事项

未列设备没有现成配置：设备支持范围由仓库现有的 compilecfg 与 deconfig 文件决定，未列出的设备不能仅靠命令参数直接获得对应构建配置。
刷机有风险：固件要刷进路由器或 x86 设备才算数，刷错固件可能导致设备无法启动，动手前确认型号、备份原厂固件、留好救砖办法。
构建资源要求实在：固件编译对磁盘空间、内存以及文件系统大小写敏感性有要求，资源不足或路径环境不合适时可能无法完成构建。
移除片段不等于删配置：移除配置片段只会阻止该片段追加，不会反向删除设备配置或 compile_base.config 中已经声明的选项，清理配置要直接改源头文件。
可复现性看配置：构建依赖上游源码、feeds、补丁和网络下载流程，具体可复现性取决于配置文件指定的仓库、分支、提交和外部资源，换环境先对配置。
默认软件包要自己核：公开信息有限，各设备的具体默认软件包、补丁内容及长期维护状态，需要结合 README、配置文件和源码确认。

适用人群

wrt_release 适合需要为指定路由器或 x86 设备重复构建定制 OpenWrt、ImmortalWrt 或 LiBwrt 固件的开发者、固件维护者和具备 Linux 编译环境的高级用户。只想给自家一台路由器刷一次第三方固件的人不适合从这套脚本起手，直接找对应设备的现成固件更省事。团队场景里，它适合作为多设备固件的统一构建入口，而不是一次性尝鲜工具。

选型建议

当你需要多设备配置复用、可选配置片段、补丁与 feeds 编排，并希望在本机或 Docker 中统一构建时，可以优先评估 wrt_release。选型前确认目标设备是否存在对应配置，核对上游源码和分支是否满足需求，并验证存储、内存、网络下载和 Docker 条件。明确的取舍是：它强在多设备、多上游的编排能力，弱在只服务已列设备、且要求使用者自己扛构建环境和刷机风险。若只需一次简单的官方源码编译，直接使用相应上游项目的标准构建流程可能更合适，不必引入这套编排。