Ext JS 7 GPL 下载与 Sencha Cmd 多版本切换实践指南

简介：这份压缩包收录了 ExtJS 7.0.0 GPL 完整发行版，面向使用 Sencha 技术栈的中高级前端与全栈开发者；内含框架源码、主题样式与命令行工具链配套资源，解决从 UI 组件选型到项目构建打包的整套流程。包内共 2000 个文件，约 229.87MB，以 png/gif 图标素材、js 源码、scss/css 主题样式、md 文档、字体及构建配置文件为主，覆盖 Modern/Classic 双主题及全部主题变量的调试与压缩版本。随包附带的 Sencha CMD 各版本下载地址，便于按项目选择适配工具；7.0.0 支持组件化、响应式布局、双向数据绑定、MVC 架构与丰富图表，开发者可基于 GPL 协议自由使用和二次分发。已有 307 人学习下载，适合需要快速搭建 ExtJS 7 项目、研究主题机制或切换历史版本工具的开发者。

1. 拿到 ext-7.0.0-gpl.zip 只是开始：版本管理才是 Ext JS 项目里最容易被低估的事

有人丢给你一个 ext-7.0.0-gpl.zip，你是不是以为解压就能开始写代码？我见过不少团队在第一步就翻车：zip 有了，Sencha Cmd 版本对不上，工作区生成不了，接着一整周都在跟构建工具搏斗。这里的关键不在 zip 本身，而在 Sencha Cmd 的各个版本怎么下载、怎么装、怎么切换。

本文会围绕 ext-7.0.0-gpl.zip 讲清楚 GPL 版本怎么选，Sencha Cmd 各版本的下载入口和找法，以及多版本共存时的 switch 用法。适合刚接手 Ext JS 老项目、或者正在从 Ext 6 往 7 迁移的从业者。我会把我自己下载、安装在本地环境的完整思路拆给你，踩过的坑也都标出来。

2. 为什么是 ext-7.0.0-gpl.zip：GPL 版本与 Sencha Cmd 的配套关系

2.1 GPL 分支解决什么问题

Ext JS 7.0.0 GPL 可以理解为一个“无授权门槛”的 SDK 包。它不需要注册开发者账号就能拿到完整框架，也不需要再额外引入试用限时、水印或者远程校验。对个人开发者、内部系统、培训机构来说，这是上手成本最低的方式。它和商业版在代码模块上的差别并不在框架本身，而在于授权条款：GPL 项目的产物如果对外分发，就得遵守 GPL 的开源义务；如果只在自己公司内网跑，闭源使用是没有问题的。

很多人看到 GPL 就担心“公司项目不能用”。真实情况要分场景：你开发的系统不做商业分发，只给内部员工用，GPL 代码进去之后，相关的衍生代码通常不需要开源；你做的产品要卖给第三方、部署在客户环境，那就要仔细评估 GPL 传染性。我一般建议，确有一定商业性质的对外项目，不要碰 GPL 包，买商业授权或者换技术栈。本文讨论的是 GPL 包，所以默认你的使用场景符合 GPL 义务范围。

从实际交付看，ext-7.0.0-gpl.zip 里包含了什么才是更值得关注的点。里面除了 Ext JS 的源码和构建产物，还有示例、资源文件、以及一套基于主题的 scss 变量体系。相比 Ext 6，Ext 7 把 toolkit 分成 classic 和 modern 两套指标体系，构建时通过app.json里配置的toolkit来决定打哪套。官方 SDK 的目录结构里能直接看到modern和classic两个目录，这和你之前在 Ext 5/6 里只面对一套 ui 组件的经验很不一样。

实际使用时，你需要理解classic是为了兼容旧版 Ext JS 的视图层设计，modern才是面向移动端和 MIT 风格的新体系。同一个 Ext 7 项目里，通常只会二选一，而不是两套混用。如果你手里的老项目是 Ext 6 时代用 classic 写的，迁移到 Ext 7 时大概率还继续用 classic；如果是从零开始的新项目，我建议认真评估 modern，因为它的网格、表单、面板组件在交互手感和构建体积上都更接近现在的 Web 前端习惯。

2.2 Sencha Cmd 在构建链里的实际位置

Sencha Cmd 不是 Ext JS 的运行库，它是包在框架外面的一层工程化工具。没有它，你也可以通过手动引入ext-all.js把页面跑起来，但一旦项目做到几十个 view、上百个组件，手动管理脚本顺序和依赖就变成一场灾难。Sencha Cmd 提供的是从工程初始化、依赖分析、代码合并、压缩混淆、到多环境构建的完整链路。

常见做法是，先把ext-7.0.0-gpl.zip解压到某个固定目录，然后安装对应版本的 Sencha Cmd，在项目里通过sencha generate app创建工程。sencha命令会读当前目录下的app.json，其中framework字段指向本地 SDK 路径或版本号，toolkit决定构建哪一套界面。开发者写代码时不需要关心脚本顺序，Cmd 会做依赖树的静态分析；发布时执行sencha app build production，它会把所有必要代码打成少数几个文件，并加上版本指纹。

这里特别要注意，Cmd 的版本必须与 Ext JS 的版本匹配。我把版本匹配放在这么靠前的位置，是因为我在 Ext 6 时期就吃过亏：用 Cmd 5.x 去编译 Ext 6 工程，报错信息奇奇怪怪，半数出现在sencha app build的代码生成阶段，而不是编译阶段。装完 6.x 的 Cmd 之后，同一份工程一次通过。所以，任何涉及 Ext 7.0.0 的构建，都建议先把 Cmd 的版本锁定到 7.0.x。

在整个开发循环里，Sencha Cmd 会承担三件高频工作：一是生成新工程和代码骨架，减小手工创建文件的成本；二是监听文件变化并增量编译，也就是sencha app watch做的事；三是产出多环境构建包，比如 development / testing / production。你在本地日常用的其实是前两件，发布到服务器时才是第三件。所以 Cmd 装不对，最糟糕的不是构建不过，而是你根本进不了日常循环。

2.3 版本配套：先看看你手里的组合是不是能跑起来

在动手下载之前，先确认一个组合关系。下面这个表是我自己整理的判断基线，覆盖大多数从 6 往 7 迁移的场景。

注意：这里写的版本系列不是官方兼容表的完整抄录，是一个经验基线。你真正站在工程里时，要以官方发布说明为准，尤其是 Cmd 的“最低版本”与“推荐版本”两列。

如果已经拿到 ext-7.0.0-gpl.zip，最省事的方式是下载对应系列的 Cmd 7.0，而不是继续用旧版本。有人会问：既然 Cmd 6.5 能构建 Ext 6.5，为什么要升级到 7？因为 Ext 7 的app.json里新增了toolkit等字段，框架自带的package.json增加了模块引用，旧版 Cmd 的解析器不认识这些字段，构建阶段会直接忽略或报错。你花在排查报错上的时间，远大于一次升级 Cmd 的时间。

这一章最后提醒一点：GPL zip 里通常没有 Sencha Cmd 本体，它是分开发布的。所以题目里“附带各个版本下载地址”这个价值点，重点落在 Cmd 的版本管理上，而不是 zip 本身有多神奇。

3. 从官网到本地：ext-7.0.0-gpl.zip 与 Sencha Cmd 各个版本下载地址怎么找

3.1 先确认下载入口，再谈文件名

我不建议直接拿文件名去搜索引擎碰运气，原因很简单：官方下载链接会带版本路径和时间戳，旧链接经常失效。更好的做法是先找到官方下载页，再从版本列表里定位你要的 zip。

打开官方下载页后，一般会有两个入口：一个是“当前版本”或“推荐下载”，另一个是“历史版本”或“Archive”。ext-7.0.0-gpl.zip 属于 7.0.0 时期的 GPL 发布，通常不会出现在最新推荐里，因为官方后续已经更新到更高版本；你需要进历史版本归档，按版本号过滤。

Sencha Cmd 各个版本也一样。Cmd 的下载页会按版本列出安装包，命名规则大致是SenchaCmd-版本号-平台.扩展名，例如 Linux 下是.sh，Windows 下是.exe，macOS 下是.dmg。真正的版本号通常包含四段，例如7.0.0.42这个样子，但不要被这种四段号吓到，前两段与 Ext JS 的对应关系最有用。

下载之前，还要养成校验文件完整性的习惯。大 zip 从网络传输中损坏的概率并不低，我在一次内网迁移时就遇到过 zip 大小差 3MB，解压到最后报 CRC 错误的情况。官方页面如果给了 sha256 校验值，下载后立刻执行：

# 校验 ext-7.0.0-gpl.zip 的 sha256 值 shasum -a 256 ext-7.0.0-gpl.zip # 把输出和下载页上公示的校验值逐位比对

这个shasum命令在 macOS 和 Linux 都有；Windows 可以打开 PowerShell 用Get-FileHash -Algorithm SHA256。不要只看文件大小，网络加速工具修改文件后，大小可能不变，但内容已经不对。校验值一致，再继续后续安装；不一致，就删掉重下，不要心存侥幸。

如果官方下载页没直接显示 sha256，也可以先下载一个小体积的.md5文件，再用md5sum -c校验。更稳妥的做法是下载完 zip 后先用unzip -l看一下文件列表，确认里面的目录层级是对的。校验不只是为了防篡改，更多时候是为了防传输损坏。我见过有人解压到一半报错，最后对比下载源才发现是浏览器插件改写了响应内容。

3.2 从页面接口提取 Sencha Cmd 各个版本下载地址

有的官方下载页不会一次性把所有历史版本铺在页面上，而是用一个脚本接口返回版本 JSON，点“加载更多”时才渲染列表。这时候，与其手动记链接，不如直接在浏览器 Network 面板里找接口。

我的做法是打开下载页，按 F12 打开开发者工具，切到 Network 面板，刷新页面，然后点击“历史版本”或“全部版本”按钮。面板上会出现一个 JSON 请求，里面包含版本号、文件名和下载地址。把这个 JSON 保存成文件，再写一个小脚本过滤。

下面这个 Python 脚本读取由浏览器保存下来的cmd-versions.json，筛选出 7.0.x 系列版本并打印文件名和地址：

import json from pathlib import Path raw = Path("cmd-versions.json").read_text(encoding="utf-8") items = json.loads(raw) # 假设 JSON 结构是列表，每个元素包含 version 和 url 字段 for item in items: version = item.get("version", "") if version.startswith("7.0."): print(f"{version}\t{item.get('url')}")

这段脚本的关键在于startswith("7.0.")，它过滤掉 6.x 和 8 开头的版本。如果你的目标是 6.5 系列的 Cmd，把判断条件改成version.startswith("6.5.")就行。如果 JSON 结构不是列表，而是嵌套在某个字段下面，需要先打印raw[:500]看结构，再调整取值字段。

注意：不同时期的下载页接口字段名不一样，可能是version和url，也可能是name和source。脚本跑不起来时，先打印一条完整记录，对着字段名改，而不是猜。

如果你更习惯命令行，也可以用 Bash 处理浏览器保存的 HTML 文件。下载页另存为本地 HTML 后，用 grep 提取所有href中包含cmd或ext-7.0.0的链接：

# 从另存为的 sencha-download.html 里提取下载地址 grep -oE 'href="[^"]*(ext-7\.0\.0|SenchaCmd)[^"]*"' sencha-download.html \ | sed 's/^href="//;s/"$//' | sort -u

这个命令把 HTML 文件中所有相关链接提取出来，排序后去重。它不会自动判断哪个是 zip、哪个是 md5 校验文件，所以看输出时再人工筛选一遍。两条路径的效果一样：把官方页面的链接先抓到本地，再决定下一步。

3.3 为内网环境准备的批量下载策略

你要是在能上网的办公网络里下载，直接点链接就完了。让我更在意的场景是，内网服务器需要安装 Sencha Cmd 和 Ext JS SDK，但服务器本身不能出网。这时，我习惯在本地构建机上先准备一个“下载目录”，把所有版本一次性抓下来。

具体策略是先用手动方式把页面里的版本列表导出成纯文本，再用下载工具批量拉取。目录结构建议按“工具类型 / 版本号 / 平台”组织，例如：

downloads/ sencha-cmd/ 7.0.0.x/ SenchaCmd-7.0.0.x-linux-amd64.sh SenchaCmd-7.0.0.x-windows-x64.exe SenchaCmd-7.0.0.x-osx-x64.dmg ext-gpl/ 7.0.0/ ext-7.0.0-gpl.zip

为什么建议按版本号分目录？因为多版本共存时，你始终需要区分“哪个 cmd 对应哪个 ext”。混放在一个目录下，到了内网机器上无法确定组合关系。按版本号建目录，再配合一份versions.txt说明文件，就能把下载阶段和安装阶段的上下文隔离开。

批量下载后，建议顺手保存一份 SHA256 清单。在 Linux/macOS 上用：

# 为当前目录下所有安装包生成校验清单 find . -type f \( -name "*.zip" -o -name "*.sh" -o -name "*.exe" -o -name "*.dmg" \) \ -exec shasum -a 256 {} \; > checksums.sha256

之后换机器或者团队其他人来接手，只需要一条命令看清单对不对：

# 校验整个目录中的文件是否与清单一致 shasum -a 256 -c checksums.sha256

这条命令输出OK表示文件完整，输出FAILED的条目要重点检查。我通常是“先校验，再解压，最后删除原包”，避免原包占空间，也避免解压一半时才发现文件是坏的。

4. 安装与多版本共存：用 Sencha Cmd switch 管理 Ext JS 7 和旧版项目

4.1 安装前的环境准备

装上 Cmd 之前，先确认 Java 环境。Sencha Cmd 是基于 Java 的工具，虽然新版一直在减少对本地 Java 的依赖，但构建阶段仍然可能调用 Java 工具来做资源处理和代码编译。为了少踩坑，我会先保证系统里有一个稳定版本的 Java，并把JAVA_HOME指向它。项目里如果没有特殊要求，选 Java 8 或 Java 11 都可以，关键是不要同时装一堆 Java 版本导致 PATH 混乱。

Node.js 不是必须的，但 Ext JS 7 的部分 npm 化示例和包引用会用到它。如果你的项目只是用 GPL zip + Cmd 构建，不跑 npm 链路，可以不装。可一旦app.json里引用了外部 npm 包，Cmd 构建时会调起 npm 解析依赖，没有 Node 就会在依赖处理阶段失败。我一般会把 Node.js 一并装上，版本不要太新，LTS 即可。

目录规划也很重要。我习惯把 Ext JS SDK 放在类似~/extjs/的目录下，把 Sencha Cmd 放在~/bin/或/opt/下，而不是直接解压到项目目录里。这样多个项目可以共用同一份 SDK 和 Cmd，版本切换时只需要改配置，不用重新下载。

环境变量也需要看一眼：

# 确认 JAVA_HOME 和 sencha 命令是否已经在 PATH 中 echo $JAVA_HOME which sencha

如果which sencha找不到，就把 Sencha Cmd 安装目录下的bin路径加入PATH。这一步做对了，后面的sencha switch才有意义，因为切换命令管理的也是这个入口。

4.2 把 ext-7.0.0-gpl.zip 安装到本地 SDK 仓库

“安装”这个词听起来很正式，实际操作其实就是解压到一个固定目录。下载完成后，把 zip 放到想长期保存的位置，再解压：

# 创建 SDK 目录并解压 mkdir -p ~/extjs unzip ~/downloads/ext-7.0.0-gpl.zip -d ~/extjs/ # 解压后得到 ~/extjs/ext-7.0.0-gpl

解压后建议先确认目录里的关键文件是否存在：

ls -la ~/extjs/ext-7.0.0-gpl/ # 应该有 build、classic、modern、examples 等目录

如果缺少classic或modern目录，说明下载的不是完整 GPL 包，可能只是某个轻量包，构建时按 toolkit 找资源会失败。完整 GPL 包解压后，ext-all.js不是直接放在根目录，而是在build/下面，这点和 Ext 5 及以前很不一样。

4.3 用 sencha switch 切换 Cmd 版本

Sencha Cmd 自带多版本管理能力。它允许在同一台机器上安装多个 Cmd 版本，并用sencha switch在版本之间切换。我第一次知道这个命令时，还在一台机器上手动改 PATH，后来才发现官方早就做了切换机制。

切换之前，先看看当前生效的是哪个版本：

# 查看当前 Sencha Cmd 版本和安装路径 sencha which

这个命令输出类似Sencha Cmd 7.0.0.xxx以及安装目录。如果输出是版本号不对，不要继续生成 App，先把版本切到目标版本。

切换版本的命令是：

# 切到 7.0.0 系列的某个 Cmd 版本 sencha switch 7.0.0.xxx

版本号的后三位有可能影响具体功能。7.0.0 的补丁版之间，API 一般稳定，但构建产物可能有差异。我会在项目根目录用app.json里的cmd配置锁定版本，而不是只靠全局切换。你会发现，同一个终端窗口里切换后，sencha which的输出会立即改变。

如果你的 Cmd 版本较新，switch参数可能需要稍微调整。最常见的兼容做法是先看本机装了哪些版本：

# 列出本机已安装的 Sencha Cmd 版本（部分版本用 --list 参数） sencha switch --list

如果命令提示参数不存在，就查一下sencha help switch。不同小版本的参数格式可能略有差异，但这不影响手段本身。真正要注意的是：切换是针对当前终端会话还是全局生效。需要跨项目稳定时，我建议在每个项目根目录里固定版本，不要依赖全局状态。

4.4 初始化一个项目并验证整条链路

安装完成之后，最好在一分钟之内验证整条链路是否走通。我会用最小命令在临时目录生成一个工程：

# 使用 ext-7.0.0-gpl SDK 生成一个名字为 MyApp 的工程 cd ~/workspace sencha -sdk ~/extjs/ext-7.0.0-gpl generate app MyApp ./myapp

这里-sdk参数指向的是第 4.2 步解压出来的 SDK 目录，generate app后面的MyApp是应用名，./myapp是生成目录。应用名必须是一个合法的 JS 类名，不能带横杠或数字开头，否则 Cmd 生成代码时会报类名错误。

生成完成后，在项目目录里启动开发模式：

cd ./myapp sencha app watch

app watch会启动一个开发服务器，监听源码变化并实时编译。启动成功后，控制台会打印本地访问地址。这段验证的价值在于把“SDK 路径是否有效”“Cmd 版本是否匹配”一次性检查完。如果 watch 能起来，说明版本配套没问题，后面就可以开始写页面了。

如果generate app就报错，优先看报错里是否出现framework、toolkit等关键词。出现这些词时，问题大概率出在 Cmd 版本不是 7.0 系列，而不是 SDK 路径错误。此时切一下 Cmd 版本，再重跑生成。

5. 下载、安装、编译阶段避坑记录：我在这条链路上踩过的 5 个坑

5.1 下载链接传给别人就失效，页面入口反而稳定

现象：我同事把从下载页复制出来的安装包链接贴到内部文档里，第二天别人打开就 404。链接里带了一串代表版本时间的参数，官方的下载链接会被系统定期清理，尤其是历史版本的归档地址。

原因：下载页里展示的链接，很多是动态生成且带签名的地址，有效期只有若干小时，不适合长期保存。存入文档后，过期是正常的。

解决：不要保存最终链接，保存官方下载页的入口位置和操作路径，例如“打开下载页-历史版本-找 SenchaCmd 7.0.0 的 Linux 安装包”。如果一定要保存链接，保存接口返回的 JSON，而不是图片、按钮上的下载 URL，因为 JSON 里的原始地址还可以根据版本号重新拼接，存活期更长。

5.2 GPL 包解开后缺少完整框架文件

现象：解压ext-7.0.0-gpl.zip后，根目录只有build.xml和package.json，找不到classic和modern目录，更找不到ext-all.js。生成 App 时，Cmd 报 SDK does not exist 或类似的路径错误。

原因：下载的其实是“bootstrap/seed”性质的压缩包，或者更小体积的某个中间产物，而不是完整 GPL SDK。完整包会在根目录出现classic、modern、build、examples等顶层目录。

解决：回到下载页，确认文件的大小信息。完整ext-7.0.0-gpl.zip应该是几百 MB 级别，如果下载下来的只有几十 MB，基本就是拿错了。另一个办法是用unzip -l列出包内容，看有没有ext-all.js和classic目录，有再解压。不要试图用“少了目录不影响”的心态继续，后面每个构建步骤都会追着你报错。

5.3 版本不匹配：framework 7.0 配 Cmd 5.x 报错

现象：用 Cmd 5.x 执行sencha app generate时，命令能执行，但生成过程很慢，最后报 “Framework FQN” 或 “theme not found” 一类异常。还有人用 Cmd 6.0 编译 Ext 7，报错信息出现在样式编译阶段，提示缺少theme-material。

原因：Cmd 内部有一套框架元数据解析器，Ext 7 的工具包机制和主题包结构都改了，旧版解析器无法正确解析新版 SDK，于是把主题路径都指向了不存在的位置。

解决：直接用 Cmd 7.0 系列。没有旧版本需求的话，不要降级。如果你需要同时维护 Ext 5 和 Ext 7 项目，用sencha switch在项目目录间切换，或者在每个项目根目录的.sencha/cmd里配置不同的版本约束。

5.4 内网离线环境执行 Cmd 安装脚本失败

现象：把.sh安装包拷到内网机器，执行后提示下载某个运行时组件失败，安装中断；有的版本会先解压到临时目录，再联网拉取 Java 相关组件，离线环境下必挂。

原因：部分 Sencha Cmd 安装器不是纯粹的自解压包，它安装完成后会尝试拉取配套工具或更新组件。内网没有代理或白名单，拉取失败，安装器就回滚。

解决：在内网搭建本地代理或镜像服务，或者预装安装器所需的外部运行时。更省心的方案是，找一台能联网的机器安装好完整 Cmd，把整个安装目录打包，再拷贝到内网解压，并把sencha命令所在目录加入 PATH。检查是否能跑：

# 在内网机器上检查 Cmd 是否被正确安装 sencha which

输出版本号且不报网络错误，就说明离线环境已经可用。如果还报网络错误，检查 Cmd 的配置里是否有指向外网的更新服务器，手动关闭自动更新。

5.5 路径带空格或中文导致 sencha 命令静默失败

现象：目录名写成D:\work\ext 7 trial\myapp或D:\项目\myapp，执行sencha app build时开始正常，跑到一半提示找不到某个中间文件，有时甚至没有任何报错，只是构建产物缺失。

原因：Cmd 内部会调用一系列基于路径拼接的工具，路径中的空格和中文在多级脚本传递时没有被统一转义，导致后续文件定位失败。

解决：项目工作区、SDK 目录、Cmd 安装目录都不要放在带空格或中文名的路径下。这条听起来像玄学，但我在真实项目里遇过不止一次。若你的既有工程已经放在这类路径，建议迁走，不要改编码或者折腾环境变量，迁走最直接。路径迁移后记得检查app.json里的绝对路径引用是否也被同步修改。

6. 把各版本下载地址与校验值做成索引，换机后五分钟恢复环境

经历了第 5 章的坑之后，建议你从第一次下载就把信息固化下来。我这里说的信息，不是“下载链接”，而是“从哪里进入下载页 + 文件名 + 校验值 + 配套关系”。这样换机器或者同事接手时，不需要重新搜一遍。

我在团队里习惯建一个build-env目录，里面放一个versions.json：

{ "extjs": [ { "version": "7.0.0", "archive": "ext-7.0.0-gpl.zip", "page": "官方下载页 -> GPL/历史版本", "sha256": "替换成下载页公示的校验值", "note": "完整 GPL SDK，包含 classic/modern" } ], "sencha-cmd": [ { "version": "7.0.0.x", "archive": "SenchaCmd-7.0.0.x-linux-amd64.sh", "page": "官方下载页 -> Cmd -> 历史版本", "sha256": "替换成下载页公示的校验值", "note": "配合 Ext 7.0.0 使用" } ] }

这个文件的价值在于把“人肉记的东西”变成可检查的清单。每次下载完，用下面这个 Python 脚本扫描本地文件，看看校验值是不是与记录一致：

import json import pathlib import hashlib idx = json.loads(pathlib.Path("versions.json").read_text(encoding="utf-8")) for group in ("extjs", "sencha-cmd"): for item in idx[group]: f = pathlib.Path(item["archive"]) if not f.exists(): print("缺失:", f) continue digest = hashlib.sha256(f.read_bytes()).hexdigest() ok = digest == item["sha256"] print(("OK " if ok else "FAIL ") + f.name)

在索引里不要只记一个下载链接，把下载入口页面、文件大小、版本搭配三样都记上。以后换机，新机器只需要装 Java、Node、复制索引、下载对应文件，再用上面的校验脚本扫描一遍，整个过程不用五分钟。

我现在的习惯是先在build-env里写好这套清单，再动手下载。这样每次从零搭建环境，都有一张地图可查，而不是靠记忆和搜索。希望帮到你。

本文还有配套的精品资源，点击获取