简介：一份ExtJS 7.0.0 GPL版资源包，附带Sencha CMD各版本下载地址，专为使用ExtJS构建富客户端Web应用的前端开发者准备，可解决组件化页面开发、双向数据绑定、主题适配与工程化构建等常见问题，兼顾桌面与移动端布局需求。压缩包共2000个文件，png、gif图片素材占据多数，同时包含js核心脚本、scss/css样式表、html示例、字体与json配置等，覆盖界面布局、主题定制、组件交互等资源需求；包体大小约229.87MB。包内还收录了classic、material、neptune等多种主题的调试样式文件，便于对照学习主题切换与样式的组织方式。资源遵循GPL许可，整理了Sencha CMD各版本下载地址，可配合完成项目生成、SASS编译、代码压缩合并与生产环境打包，降低手工配置成本。目前已有307人学习下载，适合需要经典/现代双主题实践和图表可视化开发的中高级前端开发者。
1. 为什么 7.0.0-gpl 依然是很多团队绕不开的选择
我第一次注意到这份 gpl extjs 资源，是在为一个已经上线三年的内部系统补模块的时候：前端基于 Ext JS 7.0.0，团队没有预算续商业授权，项目又不能推倒重写。ext-7.0.0-gpl.zip 正好把官方 GPL 版 SDK 的源码和构建产物装在一个压缩包里，比起去官网翻历史发布页，省掉的不只是注册和审批；它同时附带的 sencha cmd 各个版本下载地址，等于把工具链的副本也留下了。适合的场景很明确：手头有旧系统要维护、想离线搭建 Ext JS 7 开发环境，或者单纯想研究 7.0 的 classic/modern 双工具包架构。接下来我就按我实际拆包、装 Cmd、生成应用和踩坑的顺序来写。
2. Ext JS 7.0.0 GPL 包里到底装了些什么
2.1 解压 ext-7.0.0-gpl.zip 后，先看明白这套目录骨架
拿到压缩包先别急着跑命令，第一件事是看清楚 SDK 根目录长什么样。很多人在这一步就把-sdk参数指到了 build 子目录里面，后面 generate app 直接报 “SDK not found”。正确姿势是把整个压缩包原样解压，然后用 tree 确认顶层结构：
unzip ext-7.0.0-gpl.zip -d /data/sdk tree -L 1 /data/sdk/ext-7.0.0-gpl解压出来的顶层目录一般会有下面这些内容：
ext-7.0.0-gpl/ ├── build/ ├── packages/ ├── examples/ ├── index.html ├── readme.txt ├── license.txt └── version.txtbuild/里放的是已经编译好的框架产物，也就是我们后面构建应用时真正拿到的 JavaScript 和样式资源；packages/是 core、ux、locale 这些扩展包的源码和构建中间文件；examples/官方示例项目集中在这里，适合做 UI 评估但不适合直接复制到自己工程里；index.html是一个快速预览入口，双击打开能看到一个示例导航页，但要注意它只是静态演示，并不代表项目已经能用 Sencha Cmd 构建。
license.txt和version.txt是我每次拿到新包都会先打开的两个文件。前者决定你能不能在商业项目里用，后者决定 Cmd 该用哪个版本去解析框架。版本号不是只有大版本的7.0.0，里面通常还有类似7.0.0.xxx的流水号，Cmd 在比对框架时靠的就是这个流水号。
这里有一个容易被忽略的问题：build/不是单一一套文件，而是按工具包分成两套。7.0 开始在构建产出上把 classic 和 modern 分开管理，如果你只想做桌面端后台管理系统，用 classic 就够了；如果要做触屏端，则需要对应 modern 版本的产物。下面这张表是我自己的速查：
| 路径或文件 | 用途 | 常见误区 |
|---|---|---|
build/classic/ | 传统桌面组件库 | 拿 classic 的加载方式套 modern 页面会找不到组件 |
build/modern/ | 触屏与移动端组件库 | 和 classic 混在一个页面里引用会样式互相覆盖 |
build/ext-all.js | classic 全量压缩产物 | 只适合快速验证，正式项目不要直接页面引用 |
build/ext-all-debug.js | 开发调试用完整源码 | 压缩后难定位问题，调试阶段优先用它 |
packages/ | 官方扩展包源码 | 不要手动逐个去页面引，交给 Cmd 按需复制 |
examples/ | 官方示例 | 很多示例需要生成应用后才能跑，不能拿 HTML 直接双击 |
version.txt | 框架精确版本信息 | 排查依赖错位时第一件事就看它 |
2.2 版本矩阵：为什么一份 7.0.0 里会有两套开发思路
Ext JS 7.0.0 是框架在工具包设计上的一次明显转折。6.x 时代还是单一组件模型，到了 7.0，官方把组件抽象成 classic 和 modern 两个工具包，从底层packages/的划分就能看出来。classic 延续的是 6.x 那套桌面端组件体系和主题机制，适合企业后台、表单密集型页面，也更容易和旧项目衔接；modern 则基于新一代的渲染方式和触控事件模型，组件更扁平、响应式布局更自然，适合面向手机和平板屏幕的项目。
在给团队做选型时，我一般会拿两个问题来判定：第一，项目里有没有大量历史表格、复杂表单、老式树结构，这类场景 classic 的成熟度明显更高；第二，用户是不是主要用手机访问，如果是，那直接走 modern，不要幻想加个媒体查询把 classic 页面硬撑起来。7.0.0-gpl 的好处是同时给了这两套工具包，切换成本低，不用再去单独找某个版本的单独工具包下载。
有一个细节很容易翻车：同样一个组件，比如 Grid，classic 里的类名路径和 modern 里并不完全一致，API 参数也有差异。用 Cmd 生成应用时会让你指定 toolkit，默认模板是 classic。如果你后面想在一个 app 里同时跑两套，需要配置app.json里toolkit相关的多页面入口，这不是简单的复制文件。我之前见过有人把 classic 的Ext.grid.GridPanel直接用在 modern 页面里，结果组件加载不出来，控制台报一个找不到类的错误，查了半天才发现是工具包选错。
2.3 GPL 授权的边界：能省钱的地方和必须还的债
很多人看到 gpl 就以为等于“免费、随便用、闭源也行”，这是最危险的误解。GPL 版本的免费是“自由软件”意义上的免费，它允许你获取源码、修改代码、内部部署，但如果把修改后的项目以编译产物的形式对外分发，那就触发开源义务，需要以兼容 GPL 的许可证方式提供对应源码。
具体到我见到的场景，大致按两种方式区分：
- 内部管理系统：只在公司内网部署，不向客户分发安装包，GPL 限制基本不会启动；
- 商业产品前端：把构建好的
app.js和页面一起交付给外部客户，这就要认真评估 GPL 义务，不能一句“框架是免费版”就带过去。
我处理这类问题时会做两件很基本的事：一是把license.txt原样复制到自己项目的根目录，保证接手的人不会误删授权说明；二是在项目 README 里单独写一段“框架来源与许可证”，注明使用的是 Ext JS 7.0.0 GPL 包。别看这个动作简单，它对后续审计帮助很大，至少法务问起来有人能说得清楚。
提示：GPL 义务针对的是框架及其衍生作品的再分发。不要把“内部跑没问题”直接推导成“对外交付也没问题”，这两者之间的差距只有法务判断能给出权威结论。
另外一个边界是 Sencha Cmd 的授权和框架授权不是一回事。Cmd 是一套构建工具链，它本身的许可协议和框架的 GPL 协议相互独立。这份资源附带的“sencha cmd 各个版本下载地址”解决的是工具链的可获得性问题，而项目最终是否受 GPL 约束，要看你在代码里怎么使用 Ext JS 运行时。所以在写选型报告的时候，不要把“用了 GPL 框架”和理解成“整个项目必须开源”，更不要把“用了 GPL 工具链”当成项目必须开源的理由。
3. 用 Sencha Cmd 跑起 7.0.0-gpl：初始化、构建、版本对齐
3.1 先把 Sencha Cmd 装好：Java 版本和路径设定
Sencha Cmd 是 Ext JS 工程的编译引擎，负责把依赖解析、主题编译、代码合并做成一条流水线。没有它，你面对ext-7.0.0-gpl.zip只能手动引 JS，那等于回到了十年前写页面的方式。Cmd 本身依赖 Java 运行时，安装前先确认系统里有没有可用 JDK：
java -version老版本 Cmd 在 Java 8 上表现最稳定，我一般会先看自己手头 Cmd 的主版本号。如果下载的是 7.x 的 Cmd，JDK 8 或 11 都能用；但如果拿的是 6.x 的旧版 Cmd，直接塞给 7.0.0 的 SDK，构建时很可能会报框架版本不兼容，所以套件里那个“各版本下载地址”才显得有存在意义——不同 SDK 需要不同工具链版本去配套。
安装完先验证一下:
/opt/Sencha/Cmd/7.0.0.42/bin/sencha whichwhich会输出当前 Cmd 的安装路径和版本号，如果输出为空，说明安装包没解压完整，或者 JAVA_HOME 没配好。Windows 环境下更常见的现象是sencha命令能执行，但一构建就找不到 javaw.exe，这通常是系统 PATH 里指向了公共 JRE 而不是 JDK。此时把 JAVA_HOME 指到真正的 JDK 根目录，再重新打开终端即可。
注意：不要在一台机器上默认安装多个主版本 Cmd 并靠 PATH 自动选版，后面第五章会讲为什么，这里先记住，能用绝对路径就尽量用绝对路径。
3.2 用本地 SDK 生成应用骨架：关键参数与日志
这一步是整套流程里的核心动作。用刚才确认好版本的 Cmd，从本地 GPL 包直接生成一个可运行的应用骨架：
/opt/Sencha/Cmd/7.0.0.42/bin/sencha \ -sdk /data/sdk/ext-7.0.0-gpl \ generate app GplDemo /data/projects/gpl-demo这里的-sdk必须指向 SDK 顶层目录，也就是包含build/、packages/、version.txt的那个目录，不是build本身，也不是examples。GplDemo是应用名称，会直接影响命名空间和生成的类名；/data/projects/gpl-demo是工程输出路径。生成成功后，目录里会有app/、app.json、workspace.json、index.html等文件。
接着进行开发调试编译：
cd /data/projects/gpl-demo /opt/Sencha/Cmd/7.0.0.42/bin/sencha app watchwatch模式会监听源码变化，增量编译，然后启动一个本地静态服务器，默认端口一般是 1841。如果你发现页面打不开，先看控制台输出有没有提示端口冲突，如果已经有程序占用端口，可以指定参数--port换成其他端口。第一次启动时会做全量编译，耗时比较长是正常现象；二次改动后就快得多，日志里会出现类似Skipping dependency的增量处理。
这里我建议新手盯一个输出节点：日志里出现Copying X files to ...时，说明框架文件正在按你的应用配置复制到本地构建目录。如果这一步卡住或者报找不到某些包，问题大多出在 SDK 路径写错，或者是 workspace 里的路径还是旧机器的路径。
生成应用以后，你还可以根据文档模板调整入口页面。generate app默认使用的是简单后台布局，里面带一个主视图和导航菜单，这和直接去 examples 目录里双击 HTML 完全不同——skeleton 是真正做到能被 Cmd 增量编译的工程，而 examples 里的静态示例更适合看 UI 效果。
3.3 固定框架来源：workspace.json 与离线依赖
生成完工程，接下来要把框架来源固定下来。Sencha Cmd 在构建时会读workspace.json，确认应该去哪个路径加载 Ext JS SDK。如果这个文件里的路径还是生成时的绝对路径，工程拷贝到其他机器就必须同步修改，否则构建直接失败。下面是一个常见的配置片段：
{ "frameworks": { "ext": { "path": "C:/sdk/ext-7.0.0-gpl", "version": "7.0.0" } } }注意这里的path可以写成绝对路径，也可以写成相对路径，关键是保证执行sencha命令的工作目录里能够解析到它。我的习惯是写成相对路径，这样整个工程目录可以整体搬走。比如 SDK 放在工程的上级目录../sdk/ext-7.0.0-gpl，直观而且不会因为换一台机器就失效。
Cmd 在首次构建时会把需要的包从 SDK 里复制到应用的构建目录，这个过程并不强制联网。GPL 包自带完整的packages/，所以只要能把 SDK 路径读对，大多数局域网内网环境也能完成构建。但有一个边界前提：Cmd 本体的安装包必须预先下载好，因为sencha命令不会帮你从网络现拉自己。这就是附带“各版本下载地址”的实用价值——把 Cmd 安装包也归档进离线环境，整个链路才真正脱离外网。
4. 避坑排查：GPL 包实战中最常翻车的五个地方
4.1 报错Cannot find framework "ext"，多半是路径和版本表错位
典型现象：使用sencha app build时，控制台直接报找不到 ext framework，或者提示版本号是0.0.0。
原因：workspace.json里的 framework 路径没有指向正确的 SDK 根目录；还有一种可能是你打开了别人给的项目，生成时的path还是对方的/home/xxx或C:盘绝对路径，在你这台机器上当然对不上。Cmd 在解析 framework 时非常机械，路径差一级层级都会定位失败。
解决：打开workspace.json，把 path 改成当前机器上 SDK 实际所在位置；同时用version.txt核对 version 字段，不要写错主版本。改完保存，先执行一次sencha app clean，再执行sencha app build，让 Cmd 重新读取依赖。
4.2 生成的页面出现 Trial 或评估水印，先查你用的是不是真正 GPL
典型现象：应用能运行，但页面顶部或右下角出现“Trial”“Evaluation”相关提示，看起来像试用版。
原因：很多时候不是 SDK 本身的问题，而是 Cmd 在首次运行时生成了带评估标记的构建产物；也可能是你下载到的是官网试用包，而不是 GPL 包。两者文件布局长得差不多，容易混淆。
解决：先看license.txt文件内容，GPL 版本会明确写入 GPL 协议名称和版本号。然后把工程目录下~/.sencha/cmd/里的缓存清理掉，重新生成一次应用骨架。我在实践中的检验方法是：禁用本机外网访问后重新 build，如果构建完全成功且页面无水印，说明本地 GPL 包是完整的，问题就出在之前 Cmd 的远程包缓存。
4.3 启用 npm 后依赖解析绕过本地 GPL 包，版本越拉越偏
典型现象：工程里接了 npm 流程，执行npm install后，页面加载组件的顺序开始错乱，甚至Ext对象出现两个实例。
原因：package.json里依赖的 ext 相关包解析到了公网地址，npm 把另一套版本的替换文件拉进node_modules，和本地 SDK 混在一起。Cmd 的依赖解析和 npm 的解析是两个体系，同时出现很容易让构建产物混乱。
解决：如果你已经用 Sencha Cmd 生成了工程，通常不需要再把 Ext JS 重复放进 package.json。如果业务依赖跑在 npm 流程里，建议把 ext 相关依赖显式指向本地文件：
{ "dependencies": { "ext": "file:../sdk/ext-7.0.0-gpl" } }这样 npm 会以本地 SDK 为准，不再去公网解析版本。执行完npm install后重新构建，用sencha app build产物再跑一次页面，确认没有重复加载 Ext 核心文件。
4.4 构建后主题图标和字体 404，页面像失去样式
典型现象：sencha app build成功，把build/production/MyApp部署到 Nginx 后，Grid 排序箭头、按钮图标缺边框，字体文件不断报 404，样式整体偏斜。
原因：Ext JS 的主题资源里包含 icon 字体和图片，构建时这些资源会被复制到产物目录。部署到子目录时，浏览器里解析到的路径是相对根路径，找不到对应的字体目录，于是所有依赖字体的图标全部失效。
解决：部署时不要把应用直接挂在域名根目录下又不想改路径，可以在app.json的 production 构建配置里检查resources路径组织方式，比较实用的做法是在index.html头部加一个 base 标签，声明当前页面所在的相对目录：
<base href="./">另外，构建成功后先直接在本地用静态服务器预览，不要用file://协议双击打开，因为浏览器会拦截字体跨域。确认字体 404 是否复现，再决定是调整部署路径还是修改 base 标签。
4.5 多版本 Cmd 并发，PATH 里的旧版本先把构建带偏
典型现象：同一台机器上装了旧项目需要的 6.x Cmd 和新 GPL 包对应的 7.x Cmd，进入新工程执行sencha app build，提示语法不识别或者 SDK 版本拒绝。
原因：系统 PATH 里排在前面的旧版 Cmd 被优先执行，新工程的workspace.json里虽然记录了自己要的版本，但终端调用的还是旧版命令。Cmd 不像其他语言工具链那样会自动找当前目录的版本，它默认信任 PATH 里的命令。
解决：统一用绝对路径调用目标版本：
/opt/Sencha/Cmd/7.0.0.42/bin/sencha app build如果你更习惯系统命令方式，就在项目根目录写一个sencha的前置脚本，把 PATH 临时设到目标版本目录，再执行后续参数。这样既能保留旧工程继续用 6.x，不会影响新工程的构建环境。
5. 进阶技巧：把 GPL 包固化成离线物料库，让构建彻底脱离公网
5.1 第一步：把 SDK 和 Cmd 放进统一归档目录
很多团队网络受限，发布机不能访问外网。我的做法是建立一台内网构建基准机，把ext-7.0.0-gpl.zip和配套的 Sencha Cmd 安装包放在同一个固定目录下：
mkdir -p /opt/sencha-sdk mkdir -p /opt/sencha-cmdSDK 可以保持压缩包原始状态归档，但项目里workspace.json必须指向解压后的目录。我一般解压到/opt/sencha-sdk/ext-7.0.0-gpl，这个路径会成为所有历史项目共同的 framework 引用地址。新来的机器只要保持同一路径结构，构建脚本不需要为每台开发机单独改写。
Cmd 的安装包按版本号保存，例如/opt/sencha-cmd/SenchaCmd-7.x.run.zip。安装时不需要特意解压到系统特殊目录，放在/opt/Sencha/Cmd/即可，关键在于把版本目录固定文档化，避免团队成员各装一套版本。
5.2 第二步：断网环境跑一次全量构建验证
离线物料的可用性必须用一次断网构建来验证。我会在断网机上把 SDK 路径对上，然后用明确的 Cmd 版本执行：
/opt/Sencha/Cmd/7.0.0.42/bin/sencha \ -sdk /opt/sencha-sdk/ext-7.0.0-gpl \ generate app OfflineDemo /data/offline-demo cd /data/offline-demo /opt/Sencha/Cmd/7.0.0.42/bin/sencha app build构建完成后检查产物目录：
grep -r "http://" build/production/OfflineDemo/app.js如果 grep 结果里没有任何外部 URL，说明框架资源、字体、主题全部从本地 GPL 包解析，这套离线物料库就算真正立住了。从那以后，我每次拆新版 SDK 都会强制走一遍这个流程：先建固定目录，再按版本归档 Cmd，最后用断网构建验证产物。一来避免线上发布时临时发现网络依赖，二来后补的人接手时也能照着同样步骤还原环境。如果你也在折腾 Ext JS 7 历史版本或 GPL 方案，这套离线归档思路能省掉不少翻车回退的功夫，希望帮到你。
本文还有配套的精品资源，点击获取
