简介：这份资源面向使用 ExtJS 构建富客户端 Web 应用的前端开发者，提供 ext-7.0.0-gpl.zip 源码包，并附带 Sencha CMD 各版本下载地址，帮助解决框架获取与配套命令行工具版本匹配的问题。压缩包共约 2000 个文件，整体约 229.87MB，以 png、gif 等主题图片资源和 js、scss、css 等框架源码与样式文件为主，另含 ttf、eot、woff 等字体文件及 json、xml、md 等配置与说明文档，覆盖现代与经典两套主题的完整资源。ExtJS 7.0.0 提供表格、面板、表单等可定制组件，支持响应式布局、双向数据绑定、MVC 架构与多种图表，Sencha CMD 则负责生成项目结构、编译 SASS、压缩合并 JS 及构建打包。目前已有 307 人学习下载，适合需要研究框架源码、搭建本地开发环境或按项目需求选择 CMD 版本的前端工程师参考使用。
1. 拿到 ext-7.0.0-gpl.zip 和 Sencha Cmd 各版本，先搞清楚这套组合到底能干什么
如果你正在维护一套跑了七八年的企业后台，前端还是 ExtJS 那套经典桌面风格，那你大概率遇到过这个场景：想升级到 7.x，结果发现官方下载入口改来改去，GPL 版和商业版混在一起，Sencha Cmd 的版本又和框架版本对不上，构建直接报错。ext-7.0.0-gpl.zip就是 ExtJS 7.0.0 的 GPL 授权完整包，配合 Sencha Cmd 使用，能做经典的 MVC/MVVM 应用开发、主题编译和生产构建。它适合两类人：一是维护存量 ExtJS 项目的工程师，二是想研究这套老牌企业级框架架构的人。GPL 版功能完整，但授权条款要自己看清楚，商用闭源场景需要走商业授权，这点先心里有数。
2. ExtJS 7.0.0 GPL 包的结构与 Sencha Cmd 版本匹配逻辑
拿到压缩包别急着解压到项目里，先搞清楚里面有什么、Cmd 该用哪个版本，否则后面构建报错会浪费你半天时间。
2.1 解压后先看目录：哪些是框架核心，哪些是工具链
ext-7.0.0-gpl.zip解压后是一个标准的 ExtJS SDK 目录，常见结构如下：
| 目录/文件 | 作用 | 是否必须保留 |
|---|---|---|
ext-7.0.0/ | 框架根目录 | 是 |
classic/ | 经典桌面端组件与主题 | 做桌面端必须 |
modern/ | 现代移动端组件与主题 | 做移动端必须 |
packages/ | 官方扩展包（如 charts、ux） | 按需 |
build/ | 预构建的压缩版 | 生产环境可用 |
cmd/ | Sencha Cmd 相关配置模板 | 是 |
examples/ | 示例代码 | 可删 |
docs/ | 文档 | 可删 |
licenses/ | 授权文件 | 保留备查 |
我一般会把整个 SDK 放到项目外的独立目录，比如D:\sdk\ext-7.0.0，然后在项目里通过sencha.cfg或app.json指向它。这样多个项目可以共用一份 SDK，省磁盘也省得每个项目都复制一遍。
提示：
examples/和docs/加起来能占几百 MB，如果只是做项目开发，删掉不影响构建，但建议先备份。
2.2 Sencha Cmd 版本怎么选：不是越新越好
Sencha Cmd 和 ExtJS 框架之间有明确的兼容矩阵。7.0.0 这个版本，官方推荐搭配 Cmd 7.0.x 系列。用 Cmd 6.5 去构建 7.0.0 项目，大概率会在主题编译阶段报Sass compilation failed；用 Cmd 7.5 去构建，又可能因为配置项变更导致app.json解析异常。
常见做法是：框架版本号的前两位决定 Cmd 的大版本。7.0.0 对应 Cmd 7.0.x，7.1.0 对应 Cmd 7.1.x，以此类推。如果你手头有多个不同版本的 ExtJS 项目，建议把对应版本的 Cmd 分别安装到不同目录，通过环境变量切换，而不是全局只装一个。
安装 Cmd 时，Windows 下直接跑安装程序，Linux/macOS 下解压后把sencha可执行文件加入PATH。验证安装：
sencha which这条命令会输出当前 Cmd 的安装路径和版本号。如果提示找不到命令，检查PATH是否包含 Cmd 的bin目录。
2.3 用 Cmd 生成第一个 7.0.0 项目骨架
确认 Cmd 版本正确后，用以下命令生成一个标准项目：
sencha -sdk /path/to/ext-7.0.0 generate app MyApp /path/to/MyApp参数说明：
-sdk：指向解压后的 ExtJS 7.0.0 SDK 根目录，不是压缩包本身。generate app：生成应用骨架。MyApp：应用名称，会作为命名空间使用。- 最后一个参数：项目输出目录，必须为空或不存在。
执行成功后，目录里会出现app/、classic/、modern/、resources/、app.json、build.xml等。app.json是核心配置文件，里面记录了框架路径、主题、构建配置。打开它，确认"framework": "ext"和"toolkit": "classic"（或modern）是否符合你的目标平台。
注意：如果生成时报
Failed to determine framework name，多半是-sdk路径写错了，或者 SDK 目录下缺少cmd/子目录。
3. 构建、主题编译与生产打包的实操步骤
项目骨架有了，接下来是让它能跑起来、能打包。ExtJS 的构建体系基于 Sencha Cmd 和 Ant，理解几个关键命令就能覆盖大部分场景。
3.1 开发模式启动与实时预览
在项目根目录执行：
sencha app watch这个命令会启动一个内置的 Web 服务器，默认端口 1841，并监听文件变化自动重新构建。浏览器打开http://localhost:1841就能看到应用。app watch适合开发阶段，但它不会做代码压缩和混淆，加载的是未压缩的源码，方便调试。
如果端口被占用，可以在app.json里改"development": { "server": { "port": 8080 } }，或者用sencha app watch --port 8080临时指定。
3.2 生产构建：sencha app build的参数与输出
生产构建用：
sencha app build production构建完成后，输出在build/production/MyApp/目录下。这个目录里的文件是经过压缩、合并、混淆的，可以直接部署到 Web 服务器。
关键参数：
production：构建环境，对应app.json里的"builds": { "production": { ... } }配置。--destination：自定义输出目录，比如sencha app build production --destination /var/www/html。--clean：构建前清理旧输出，避免残留文件干扰。
构建过程中如果报Sass compilation failed，先检查app.json里"sass": { "namespace": "MyApp" }是否和项目命名空间一致。不一致会导致主题变量找不到。
3.3 主题编译：从 SCSS 到 CSS 的链路
ExtJS 7.x 的主题基于 SCSS，编译由 Cmd 调用 Ruby Sass 或 Dart Sass 完成。自定义主题的常见做法是：
- 在
packages/local/下创建主题包，或直接修改classic/theme-xxx/sass/下的变量文件。 - 在
app.json的"theme"字段指定主题名称。 - 执行
sencha app build或sencha app watch触发编译。
一个典型的主题变量覆盖示例：
// 文件：classic/sass/var/Component.scss $base-color: #2c3e50; $font-family: 'Microsoft YaHei', sans-serif;改完后重新构建，生成的 CSS 会包含新的颜色和字体。如果改了没生效，检查app.json里"sass": { "save": "sass/var" }是否指向了正确的变量目录。
提示：Cmd 7.0.x 默认使用 Ruby Sass，如果本机没装 Ruby 或版本不对，会报
sass: command not found。可以改用 Dart Sass，在sencha.cfg里设置sass.compiler=dart-sass。
4. 避坑与排查：版本、路径、授权三个高频翻车点
这套工具链的坑主要集中在版本匹配、路径配置和授权理解上，下面几条是我和同行踩过的血泪经验。
4.1 现象：sencha app build报Framework not found
原因：app.json里的"framework": "ext"对应的路径没有正确指向 SDK，或者 SDK 目录被移动过。
解决：检查app.json同级目录下是否有.sencha/文件夹，里面的sencha.cfg记录了framework.path。如果路径失效，删掉.sencha/重新执行sencha app upgrade /path/to/ext-7.0.0让它重新生成。
4.2 现象：主题编译后样式错乱，部分组件没样式
原因：SCSS 变量覆盖顺序不对，或者自定义主题包没有正确继承基础主题。
解决：确保自定义主题的sass/var/下变量文件在sass/src/之前被引入。常见做法是在主题包的sass/var/Component.scss里只放变量，在sass/src/Component.scss里放具体样式规则。另外检查app.json的"theme"字段是否指向了正确的主题包名。
4.3 现象：Cmd 版本切换后，旧项目构建失败
原因：不同 Cmd 版本对app.json的 schema 要求不同，新版本可能不兼容旧配置。
解决：每个项目锁定一个 Cmd 版本，在项目根目录放一个.sencha-version文件记录版本号，团队协作时统一。切换 Cmd 后如果报配置错误，先跑sencha app upgrade让 Cmd 自动迁移配置，再手动检查app.json里被改动的字段。
4.4 现象：GPL 版用于商业项目收到授权提醒
原因：GPL 授权要求衍生作品也开源，闭源商用不符合条款。
解决：商用闭源场景必须购买商业授权。GPL 版适合开源项目、内部学习、非商业用途。如果只是内部工具且不对外分发，也要仔细阅读 GPL 条款中关于“分发”的定义，必要时咨询法务。
4.5 现象：sencha app watch启动后浏览器白屏，控制台报 404
原因：app.json里"indexHtmlPath"指向的 HTML 文件路径不对，或者"output"目录配置和实际服务器根目录不一致。
解决：检查app.json的"indexHtmlPath": "index.html"是否与实际文件位置匹配。如果用了自定义output目录，确保app watch的服务器根目录指向正确。临时办法是删掉build/和.sencha/重新生成。
5. 多版本共存与离线部署的进阶技巧
实际工作中经常要同时维护 6.x 和 7.x 两个项目，或者在内网环境离线部署。下面两个技巧能省不少事。
5.1 用环境变量切换 Cmd 版本
假设你装了 Cmd 6.5 和 Cmd 7.0 两个版本，分别放在D:\tools\cmd65和D:\tools\cmd70。可以写两个批处理脚本：
:: cmd65.bat @echo off set PATH=D:\tools\cmd65;%PATH% echo Sencha Cmd 6.5 activated:: cmd70.bat @echo off set PATH=D:\tools\cmd70;%PATH% echo Sencha Cmd 7.0 activated需要构建哪个项目，就先跑对应的脚本，再执行sencha app build。Linux/macOS 下用alias或export PATH同理。这样比反复卸载重装干净得多。
5.2 离线环境部署：把 SDK 和 Cmd 一起打包
内网机器没法访问外网时，需要提前准备好：
ext-7.0.0-gpl.zip解压后的完整 SDK。- Sencha Cmd 安装包（Windows 是
.exe，Linux 是.run或.zip）。 - Ruby 或 Dart Sass 的离线安装包（如果主题编译需要）。
- 项目依赖的第三方包（如果有）。
部署步骤：
- 在内网机器上安装 Cmd，配置
PATH。 - 解压 SDK 到固定目录，比如
/opt/ext-7.0.0。 - 把项目代码复制过去，修改
app.json里的framework.path指向/opt/ext-7.0.0。 - 执行
sencha app build production，如果报缺少 Sass 编译器，安装离线包后重试。
注意：离线环境下
sencha app upgrade可能因为无法访问远程仓库而失败，建议在联网环境先升级好配置，再整体拷贝到内网。
5.3 验证构建产物是否可用的三个检查点
构建完成后别急着部署，先做三个检查：
- 打开
build/production/MyApp/index.html，看控制台有无报错。 - 检查
build/production/MyApp/resources/下是否有编译后的 CSS 和图片。 - 用
sencha app build testing生成测试版，对比生产版和测试版的差异，确认压缩没有破坏功能。
从那以后我每次拿到新的 ExtJS 版本包，都先跑一遍sencha which确认 Cmd 版本，再解压 SDK 到独立目录，最后才生成项目。这套流程走顺了，后面基本不会在环境上翻车。希望帮到你。
本文还有配套的精品资源，点击获取
