拓冰网站定制 
简介ExtJS 7.0.0 GPL版完整资源包定位为前端开发者构建复杂Web富客户端的工具集适合需要开源许可、希望自由定制界面的中高级JavaScript工程师。压缩包约229.87MB内含2000余个文件涵盖大量PNG、GIF图标与图片资源、JS组件脚本、SCSS/CSS主题样式、HTML示例页面及TTF字体等可直接用于离线开发与多主题界面调试。包内除ExtJS框架外还附带Sencha CMD各版本下载地址便于开发者按项目需要选择构建、打包工具。目前已有304人学习对于想快速掌握ExtJS 7组件化、响应式布局、数据绑定及MVC架构的开发者这份资源能节省收集与配置时间同时提供多套官方主题样式与可视化组件参考方便评估经典与现代主题在PC、平板和手机等项目中的实际效果。 做 Ext JS 开发的朋友迟早会遇到一个场景领导丢给你一个2019 年的老项目让你在本地把它跑起来或者你自己搜“Ext JS 下载”折腾半天发现官网要先注册、填表单、选版本甚至还要等人工确认。这时候ext-7.0.0-gpl.zip这个文件名就会反复出现在搜索结果里。配合Sencha Cmd这个官方命令行工具从创建工程到编译打包整条链路都能在本地离线完成。这篇文章就把“ext-7.0.0-gpl.zip 在哪下、Sencha Cmd 各个版本去哪找、怎么配对版本、怎么跑起一个真实应用”完整走一遍顺便把我在这个过程中踩过的坑记下来。1. 这个zip包凭什么到现在还有人翻出来用1.1 GPL v3免费且完整ext-7.0.0-gpl.zip 是 Sencha 官方发布的 GPL v3 授权完整包。所谓“完整”意思是框架日常能碰到的组件、主题、示例、构建产物全都在里面不像有些商用框架的社区版那样砍功能。对个人学习、开源项目、公司内部系统来说这个授权基本够用如果你的项目是闭源商业产品用之前自己掂量一下 GPL 的传染性需要法律判断的地方别拍脑袋。很多人误以为 GPL 包是老版本、残缺版其实从实际使用角度看GPL 包里该有的都有甚至可以直接用 IDE 定位到未压缩源码去断点调试。Sencha 把商业版的差异主要体现在授权条款、技术支持、以及一些面向企业级的协作功能上而不是你在classic/和modern/目录里能看到的那堆组件代码。1.2 7.0.0 在框架演进里的特殊位置Ext JS 7.0.0 是 7.x 大版本的第一代2019 年发布。它做了一件重要的事引入Universal Application通用应用概念让一个工程里可以同时存在 classic toolkit传统桌面端组件库和 modern toolkit触摸优先、响应式组件库。6.x 时代你必须在两者之间二选一创建工程前就得想清楚7.0 开始可以共存这对想要渐进式迁移老界面的团队非常友好。也正因为 7.0.0 是 7.x 的开山之作很多企业的技术栈直接冻结在它上面。后面 7.x 虽然一直在迭代但官方越来越推 npm 仓库方式zip 包下载入口反而越来越隐蔽直链地址就成了社区里口口相传的“珍藏资源”。1.3 离线友好对构建系统和内网环境太重要了这个包解压以后能看到build/、classic/、modern/、packages/、examples/等目录。classic/和modern/下是各自的源码和样式build/里有编译好的产物packages/里是框架运行需要的一堆依赖包。对真正在内网隔离环境里干活的人来说这一整个 zip 就是救命的不需要在部署机上配 npm、不需要拉外网仓库解压之后配合 Sencha Cmd 就能完成从生成工程到构建的全流程。即使你不在内网zip 方式也比 npm 方式可控。npm 方式要配 registry、要登录仓库、要处理版本漂移而 zip 包里的内容是一份快照团队里所有人拿到的是同一个文件构建环境可复现性高很多。2. 下载地址清单一条规律撸遍 Sencha Cmd 所有版本2.1 主角直链ext-7.0.0-gpl.zip直接给地址https://cdn.sencha.com/ext/gpl/ext-7.0.0-gpl.zip这是 Sencha 官方 CDN 的 GPL 目录不需要登录copy 到浏览器或者下载工具里就能拉。如果你打开官网发现下载入口改版了去官网 Ext JS 产品页找 GPL Download 入口也能拿到同一份文件但直链是最省事的。这个包体积不小建议用支持断点续传的下载工具别用浏览器裸下。下载完先别急着解压看一下文件大小是否完整。我遇到过下到一半中断、浏览器自动重命名成.zip.crdownload的情况这种文件解压必报错重下一遍最省心。2.2 Sencha Cmd 的 CDN 地址规律Sencha Cmd 的下载地址其实非常有规律理解规律之后你不需要收藏几十个链接只需要记住一个根地址https://cdn.sencha.com/cmd/浏览器打开这个地址你能看到一长串版本目录列表例如6.5.3.6/、7.0.0.40/、7.5.2.19/、7.6.0.87/等。每个目录里放着对应版本在不同平台下的安装包命名模式固定为SenchaCmd-版本号-平台-架构.后缀平台和架构的对应关系如下平台架构后缀Windows64 位 / 32 位windows-64bit / windows-32bitzip 或 exemacOSIntel x64darwin-x64dmg 或 zipLinuxamd64linux-amd64sh举例我实测常用的三个版本完整地址是https://cdn.sencha.com/cmd/7.0.0.40/SenchaCmd-7.0.0.40-windows-64bit.zip https://cdn.sencha.com/cmd/7.5.2.19/SenchaCmd-7.5.2.19-windows-64bit.zip https://cdn.sencha.com/cmd/7.6.0.87/SenchaCmd-7.6.0.87-windows-64bit.zipLinux 环境把最后的后缀换成linux-amd64.shmacOS 换成darwin-x64.zip即可。你也可以直接打开https://cdn.sencha.com/cmd/7.6.0.87/目录看这个版本具体提供了哪些平台的包再把链接拼出来。2.3 实用版本对照表给不同阶段的工程选 Cmd 版本大概是这么个思路Ext JS 版本推荐 Sencha Cmd 系列典型 build 示例说明6.2.x6.2.x / 6.5.x6.5.3.6老项目最稳的组合6.5.x6.5.x6.5.3.6兼容 6.x 工程7.0.x7.0.x7.0.0.40本文主角JDK 8 环境7.5.x7.5.x / 7.6.x7.5.2.197.x 中后期常用7.6.x7.6.x7.6.0.87新项目起步可用原则很简单大版本对齐。Cmd 6.x 编译 Ext 7.x 工程基本不可行而新的 Cmd 编译老的同大版本工程通常没问题。如果你手头是 Ext 7.0.0 的应用直接上 7.0.0.40 不会错。2.4 除了 zip还有一条 npm 路线7.x 之后官方也提供 npm 方式把 registry 指向https://npm.sencha.com用官网注册的门户账号登录然后npm install sencha/ext-classic7.0.0 sencha/ext-modern7.0.0这种方式的优势是依赖可以纳入 package.json 统一管理适合外部网络通畅、团队协作规范的场景。但缺点也明显每次在新机器上都要配认证信息离线或内网环境下基本不可用。我的个人看法是面对 ext-7.0.0-gpl.zip 这种老固定版本zip 方式依然是性价比最高的选择。3. 版本匹配和运行环境先想清楚再动手3.1 Cmd 与 Ext 的匹配原则Sencha Cmd 不是一个可以随便混用的工具。工程根目录的.sencha/app/sencha.cfg或app.json里通常会记录工程期望的 Cmd 版本。如果你装了不匹配的版本去构建命令行经常会直接抛类似这样的错误Sencha Cmd version X does not match project requirement Y这种报错很直接解决方法就是切换 Cmd 版本。我的建议是拿到一个工程以后先看它用的 Ext JS 是什么版本再决定用哪个 Cmd而不是拿手头最新的 Cmd 硬试。大版本不对齐生成出来的目录结构都可能不一样后面排查成本很高。3.2 JDK 版本8 还是 11 还是 17Cmd 本质上是 Java 程序运行前必须保证JAVA_HOME正确。不同版本的 Cmd 对 JDK 的容忍度差别很大我实际测试的经验如下Sencha Cmd 版本推荐 JDK备注6.xJDK 8JDK 11 部分工程会告警7.0.xJDK 8JDK 11 偶发问题JDK 17 基本跑不起来7.5JDK 8 或 JDK 11JDK 17 在新版本上可用但没必要冒险配置 JDK 时注意JAVA_HOME路径不要带空格和中文否则 Cmd 启动阶段就可能挂掉。用java -version确认当前默认版本再用echo %JAVA_HOME%Windows或echo $JAVA_HOMEmacOS/Linux确认环境变量。3.3 Windows / macOS / Linux 的安装差异Windows 上最省事的方式是下载.exe安装包运行它会自动把 Cmd 写入环境变量。如果下载的是 zip 包解压后需要手动把bin目录加入PATH否则执行sencha会提示命令找不到。macOS 上一般下载 dmg双击挂载后把内容拖到/Applications/Sencha/目录安装程序会自动处理软链终端里直接能用sencha。Linux 上给.sh加执行权限后运行默认安装到/opt/Sencha/Cmd/版本号。无论哪个平台装完第一件是执行sencha which这个命令会输出当前 Cmd 的版本和安装路径。如果这个命令能正常返回说明环境基本合格。4. 一步步跑通从解压到生产构建4.1 解压与目录结构先把ext-7.0.0-gpl.zip解压到纯英文路径例如D:\ext-7.0.0不要放在C:\Users\张三\桌面\ext-7.0.0这种带中文和空格的地方。解压后你会看到这些核心目录build/编译好的框架产物里面也有可用于快速引入的全量 JS 文件classic/经典工具包的源码、样式、主题modern/现代工具包的源码、样式、主题packages/框架依赖的包集合examples/官方示例很多组件用法可以直接在这里翻如果你不想用 Cmd只是快速做个原型可以直接在 HTML 里引用build/classic目录下对应版本的ext-all.js和主题 css走传统 script 标签方式这也是这个 zip 包的另一层价值。4.2 生成 Universal App进入命令行执行sencha -sdk D:\ext-7.0.0 generate app MyApp D:\workspace\MyApp-sdk参数必须指向 ext-7.0.0 解压后的根目录MyApp是应用名不能以数字开头第三个参数是工程要生成的路径。执行过程中 Cmd 会创建一套 universal 工程包含app/通用业务代码、classic/、modern/、workspace.json、app.json等。这里的app.json会同时声明两个 build 入口分别对应 classic 和 modern。整个过程大概几十秒到几分钟取决于机器性能。如果控制在日志里看到下载动作说明 Cmd 在尝试拉取某个缺失的包需要留意网络状态。4.3 开发模式sencha app watch进入工程目录运行cd D:\workspace\MyApp sencha app watchwatch会启动本地开发服务器同时监听源码变化做增量编译。你改完代码保存浏览器自动刷新开发体验还算顺。有一个细节值得注意7.0.0 的 universal 工程在 watch 模式下访问地址会按客户端类型决定返回 classic 还是 modern 入口所以别因为页面看起来“变了”而一脸懵这是特性不是 bug。4.4 生产构建sencha app build开发调试没问题后执行sencha app build第一次构建会比较慢因为要同时编译 classic 和 modern 两套 toolkit期间会做资源拷贝、JS 压缩、CSS 合并、依赖树摇树等操作。构建完成后的产物在build/production/MyApp/这是一份纯静态资源直接丢给 Nginx、Tomcat 或其他静态文件服务器就能跑起来。如果你的页面需要调用后端接口记得在服务器层面把/api之类的路径代理到真实后端地址别指望 Sencha Cmd 帮你解决跨域。5. 我在实际环境里踩过的 5 个坑5.1 解压就报错文件名太长Windows 自带资源管理器在解压 Ext JS 这种嵌套层级极深的 zip 时经常报“文件名太长”或者“无法访问路径过长”。换 7-Zip、WinRAR 这类工具基本能绕过去或者直接把包解压到盘根目录的短路径下比如C:\ext-7.0.0路径越短越不容易触发这个问题。5.2 JAVA_HOME 指向了 JDK 17Cmd 直接起不来我有一台新机器默认装了 JDK 17双击sencha毫无反应命令行执行也只报一个UnsupportedClassVersionError。折腾了半小时才意识到是 JDK 版本问题。换成 JDK 8 之后一切恢复正常。如果你遇到 Cmd 在启动阶段无响应或秒退先查java -version和JAVA_HOME这条经验能省一晚上的排查时间。5.3 第一次 generate app 卡在下载新的 workspace 首次生成时Cmd 有可能会从网络拉取和工程匹配的框架包。如果公司网络不稳定这一步会卡很久甚至直接失败。我的处理方式是先看控制台日志里卡在哪个 URL 上确认是网络问题后用下载工具把对应文件拉下来放到本地的 packages 目录再重新执行命令。如果每次重试都失败检查一下本地磁盘空间和杀毒软件日志别只看表面报错。5.4 杀毒软件把 sencha.exe 当风险程序个别杀毒软件会把 Sencha Cmd 的自解压程序和某些 jar 包识别为恶意程序导致 Cmd 功能异常。我自己就遇到过一次杀软直接把 Cmd 目录隔离了然后所有sencha命令都变成“不是内部或外部命令”。解决办法是把 Sencha 的安装目录和工程目录加入杀软的信任列表或排除项再重新解压一份安装包。5.5 老工程报 compass 相关错误老项目的app.json里如果有sass: { generator: compass }这类配置7.0 默认的 fashion 编译器不会接管构建时会尝试调用 Ruby/Compass环境里如果没有就报错。解决方式有两个要么在app.json里把 sass 生成器改成fashion要么老老实实装对应版本的 Ruby然后gem install compass。我更推荐前者毕竟新工具链才是长期方向除非这个工程还有别的地方依赖 compass 的特定行为。最后再分享一个维护老项目的体会版本号别乱升环境变量别乱改下载地址记得存一份。先用 7.0.0.40 把整条链路跑通再考虑升级的事情。很多所谓“框架用不了”的问题并不是框架坏了而是 Cmd 版本和 Ext 版本没配对。我自己维护一个 2019 年的项目到现在靠的就是这套固定的 zip Cmd 组合稳妥省心。本文还有配套的精品资源点击获取 Ext JS 7.0.0 GPL 包下载与 Sencha Cmd 版本匹配实战指南
简介ExtJS 7.0.0 GPL版完整资源包定位为前端开发者构建复杂Web富客户端的工具集适合需要开源许可、希望自由定制界面的中高级JavaScript工程师。压缩包约229.87MB内含2000余个文件涵盖大量PNG、GIF图标与图片资源、JS组件脚本、SCSS/CSS主题样式、HTML示例页面及TTF字体等可直接用于离线开发与多主题界面调试。包内除ExtJS框架外还附带Sencha CMD各版本下载地址便于开发者按项目需要选择构建、打包工具。目前已有304人学习对于想快速掌握ExtJS 7组件化、响应式布局、数据绑定及MVC架构的开发者这份资源能节省收集与配置时间同时提供多套官方主题样式与可视化组件参考方便评估经典与现代主题在PC、平板和手机等项目中的实际效果。 做 Ext JS 开发的朋友迟早会遇到一个场景领导丢给你一个2019 年的老项目让你在本地把它跑起来或者你自己搜“Ext JS 下载”折腾半天发现官网要先注册、填表单、选版本甚至还要等人工确认。这时候ext-7.0.0-gpl.zip这个文件名就会反复出现在搜索结果里。配合Sencha Cmd这个官方命令行工具从创建工程到编译打包整条链路都能在本地离线完成。这篇文章就把“ext-7.0.0-gpl.zip 在哪下、Sencha Cmd 各个版本去哪找、怎么配对版本、怎么跑起一个真实应用”完整走一遍顺便把我在这个过程中踩过的坑记下来。1. 这个zip包凭什么到现在还有人翻出来用1.1 GPL v3免费且完整ext-7.0.0-gpl.zip 是 Sencha 官方发布的 GPL v3 授权完整包。所谓“完整”意思是框架日常能碰到的组件、主题、示例、构建产物全都在里面不像有些商用框架的社区版那样砍功能。对个人学习、开源项目、公司内部系统来说这个授权基本够用如果你的项目是闭源商业产品用之前自己掂量一下 GPL 的传染性需要法律判断的地方别拍脑袋。很多人误以为 GPL 包是老版本、残缺版其实从实际使用角度看GPL 包里该有的都有甚至可以直接用 IDE 定位到未压缩源码去断点调试。Sencha 把商业版的差异主要体现在授权条款、技术支持、以及一些面向企业级的协作功能上而不是你在classic/和modern/目录里能看到的那堆组件代码。1.2 7.0.0 在框架演进里的特殊位置Ext JS 7.0.0 是 7.x 大版本的第一代2019 年发布。它做了一件重要的事引入Universal Application通用应用概念让一个工程里可以同时存在 classic toolkit传统桌面端组件库和 modern toolkit触摸优先、响应式组件库。6.x 时代你必须在两者之间二选一创建工程前就得想清楚7.0 开始可以共存这对想要渐进式迁移老界面的团队非常友好。也正因为 7.0.0 是 7.x 的开山之作很多企业的技术栈直接冻结在它上面。后面 7.x 虽然一直在迭代但官方越来越推 npm 仓库方式zip 包下载入口反而越来越隐蔽直链地址就成了社区里口口相传的“珍藏资源”。1.3 离线友好对构建系统和内网环境太重要了这个包解压以后能看到build/、classic/、modern/、packages/、examples/等目录。classic/和modern/下是各自的源码和样式build/里有编译好的产物packages/里是框架运行需要的一堆依赖包。对真正在内网隔离环境里干活的人来说这一整个 zip 就是救命的不需要在部署机上配 npm、不需要拉外网仓库解压之后配合 Sencha Cmd 就能完成从生成工程到构建的全流程。即使你不在内网zip 方式也比 npm 方式可控。npm 方式要配 registry、要登录仓库、要处理版本漂移而 zip 包里的内容是一份快照团队里所有人拿到的是同一个文件构建环境可复现性高很多。2. 下载地址清单一条规律撸遍 Sencha Cmd 所有版本2.1 主角直链ext-7.0.0-gpl.zip直接给地址https://cdn.sencha.com/ext/gpl/ext-7.0.0-gpl.zip这是 Sencha 官方 CDN 的 GPL 目录不需要登录copy 到浏览器或者下载工具里就能拉。如果你打开官网发现下载入口改版了去官网 Ext JS 产品页找 GPL Download 入口也能拿到同一份文件但直链是最省事的。这个包体积不小建议用支持断点续传的下载工具别用浏览器裸下。下载完先别急着解压看一下文件大小是否完整。我遇到过下到一半中断、浏览器自动重命名成.zip.crdownload的情况这种文件解压必报错重下一遍最省心。2.2 Sencha Cmd 的 CDN 地址规律Sencha Cmd 的下载地址其实非常有规律理解规律之后你不需要收藏几十个链接只需要记住一个根地址https://cdn.sencha.com/cmd/浏览器打开这个地址你能看到一长串版本目录列表例如6.5.3.6/、7.0.0.40/、7.5.2.19/、7.6.0.87/等。每个目录里放着对应版本在不同平台下的安装包命名模式固定为SenchaCmd-版本号-平台-架构.后缀平台和架构的对应关系如下平台架构后缀Windows64 位 / 32 位windows-64bit / windows-32bitzip 或 exemacOSIntel x64darwin-x64dmg 或 zipLinuxamd64linux-amd64sh举例我实测常用的三个版本完整地址是https://cdn.sencha.com/cmd/7.0.0.40/SenchaCmd-7.0.0.40-windows-64bit.zip https://cdn.sencha.com/cmd/7.5.2.19/SenchaCmd-7.5.2.19-windows-64bit.zip https://cdn.sencha.com/cmd/7.6.0.87/SenchaCmd-7.6.0.87-windows-64bit.zipLinux 环境把最后的后缀换成linux-amd64.shmacOS 换成darwin-x64.zip即可。你也可以直接打开https://cdn.sencha.com/cmd/7.6.0.87/目录看这个版本具体提供了哪些平台的包再把链接拼出来。2.3 实用版本对照表给不同阶段的工程选 Cmd 版本大概是这么个思路Ext JS 版本推荐 Sencha Cmd 系列典型 build 示例说明6.2.x6.2.x / 6.5.x6.5.3.6老项目最稳的组合6.5.x6.5.x6.5.3.6兼容 6.x 工程7.0.x7.0.x7.0.0.40本文主角JDK 8 环境7.5.x7.5.x / 7.6.x7.5.2.197.x 中后期常用7.6.x7.6.x7.6.0.87新项目起步可用原则很简单大版本对齐。Cmd 6.x 编译 Ext 7.x 工程基本不可行而新的 Cmd 编译老的同大版本工程通常没问题。如果你手头是 Ext 7.0.0 的应用直接上 7.0.0.40 不会错。2.4 除了 zip还有一条 npm 路线7.x 之后官方也提供 npm 方式把 registry 指向https://npm.sencha.com用官网注册的门户账号登录然后npm install sencha/ext-classic7.0.0 sencha/ext-modern7.0.0这种方式的优势是依赖可以纳入 package.json 统一管理适合外部网络通畅、团队协作规范的场景。但缺点也明显每次在新机器上都要配认证信息离线或内网环境下基本不可用。我的个人看法是面对 ext-7.0.0-gpl.zip 这种老固定版本zip 方式依然是性价比最高的选择。3. 版本匹配和运行环境先想清楚再动手3.1 Cmd 与 Ext 的匹配原则Sencha Cmd 不是一个可以随便混用的工具。工程根目录的.sencha/app/sencha.cfg或app.json里通常会记录工程期望的 Cmd 版本。如果你装了不匹配的版本去构建命令行经常会直接抛类似这样的错误Sencha Cmd version X does not match project requirement Y这种报错很直接解决方法就是切换 Cmd 版本。我的建议是拿到一个工程以后先看它用的 Ext JS 是什么版本再决定用哪个 Cmd而不是拿手头最新的 Cmd 硬试。大版本不对齐生成出来的目录结构都可能不一样后面排查成本很高。3.2 JDK 版本8 还是 11 还是 17Cmd 本质上是 Java 程序运行前必须保证JAVA_HOME正确。不同版本的 Cmd 对 JDK 的容忍度差别很大我实际测试的经验如下Sencha Cmd 版本推荐 JDK备注6.xJDK 8JDK 11 部分工程会告警7.0.xJDK 8JDK 11 偶发问题JDK 17 基本跑不起来7.5JDK 8 或 JDK 11JDK 17 在新版本上可用但没必要冒险配置 JDK 时注意JAVA_HOME路径不要带空格和中文否则 Cmd 启动阶段就可能挂掉。用java -version确认当前默认版本再用echo %JAVA_HOME%Windows或echo $JAVA_HOMEmacOS/Linux确认环境变量。3.3 Windows / macOS / Linux 的安装差异Windows 上最省事的方式是下载.exe安装包运行它会自动把 Cmd 写入环境变量。如果下载的是 zip 包解压后需要手动把bin目录加入PATH否则执行sencha会提示命令找不到。macOS 上一般下载 dmg双击挂载后把内容拖到/Applications/Sencha/目录安装程序会自动处理软链终端里直接能用sencha。Linux 上给.sh加执行权限后运行默认安装到/opt/Sencha/Cmd/版本号。无论哪个平台装完第一件是执行sencha which这个命令会输出当前 Cmd 的版本和安装路径。如果这个命令能正常返回说明环境基本合格。4. 一步步跑通从解压到生产构建4.1 解压与目录结构先把ext-7.0.0-gpl.zip解压到纯英文路径例如D:\ext-7.0.0不要放在C:\Users\张三\桌面\ext-7.0.0这种带中文和空格的地方。解压后你会看到这些核心目录build/编译好的框架产物里面也有可用于快速引入的全量 JS 文件classic/经典工具包的源码、样式、主题modern/现代工具包的源码、样式、主题packages/框架依赖的包集合examples/官方示例很多组件用法可以直接在这里翻如果你不想用 Cmd只是快速做个原型可以直接在 HTML 里引用build/classic目录下对应版本的ext-all.js和主题 css走传统 script 标签方式这也是这个 zip 包的另一层价值。4.2 生成 Universal App进入命令行执行sencha -sdk D:\ext-7.0.0 generate app MyApp D:\workspace\MyApp-sdk参数必须指向 ext-7.0.0 解压后的根目录MyApp是应用名不能以数字开头第三个参数是工程要生成的路径。执行过程中 Cmd 会创建一套 universal 工程包含app/通用业务代码、classic/、modern/、workspace.json、app.json等。这里的app.json会同时声明两个 build 入口分别对应 classic 和 modern。整个过程大概几十秒到几分钟取决于机器性能。如果控制在日志里看到下载动作说明 Cmd 在尝试拉取某个缺失的包需要留意网络状态。4.3 开发模式sencha app watch进入工程目录运行cd D:\workspace\MyApp sencha app watchwatch会启动本地开发服务器同时监听源码变化做增量编译。你改完代码保存浏览器自动刷新开发体验还算顺。有一个细节值得注意7.0.0 的 universal 工程在 watch 模式下访问地址会按客户端类型决定返回 classic 还是 modern 入口所以别因为页面看起来“变了”而一脸懵这是特性不是 bug。4.4 生产构建sencha app build开发调试没问题后执行sencha app build第一次构建会比较慢因为要同时编译 classic 和 modern 两套 toolkit期间会做资源拷贝、JS 压缩、CSS 合并、依赖树摇树等操作。构建完成后的产物在build/production/MyApp/这是一份纯静态资源直接丢给 Nginx、Tomcat 或其他静态文件服务器就能跑起来。如果你的页面需要调用后端接口记得在服务器层面把/api之类的路径代理到真实后端地址别指望 Sencha Cmd 帮你解决跨域。5. 我在实际环境里踩过的 5 个坑5.1 解压就报错文件名太长Windows 自带资源管理器在解压 Ext JS 这种嵌套层级极深的 zip 时经常报“文件名太长”或者“无法访问路径过长”。换 7-Zip、WinRAR 这类工具基本能绕过去或者直接把包解压到盘根目录的短路径下比如C:\ext-7.0.0路径越短越不容易触发这个问题。5.2 JAVA_HOME 指向了 JDK 17Cmd 直接起不来我有一台新机器默认装了 JDK 17双击sencha毫无反应命令行执行也只报一个UnsupportedClassVersionError。折腾了半小时才意识到是 JDK 版本问题。换成 JDK 8 之后一切恢复正常。如果你遇到 Cmd 在启动阶段无响应或秒退先查java -version和JAVA_HOME这条经验能省一晚上的排查时间。5.3 第一次 generate app 卡在下载新的 workspace 首次生成时Cmd 有可能会从网络拉取和工程匹配的框架包。如果公司网络不稳定这一步会卡很久甚至直接失败。我的处理方式是先看控制台日志里卡在哪个 URL 上确认是网络问题后用下载工具把对应文件拉下来放到本地的 packages 目录再重新执行命令。如果每次重试都失败检查一下本地磁盘空间和杀毒软件日志别只看表面报错。5.4 杀毒软件把 sencha.exe 当风险程序个别杀毒软件会把 Sencha Cmd 的自解压程序和某些 jar 包识别为恶意程序导致 Cmd 功能异常。我自己就遇到过一次杀软直接把 Cmd 目录隔离了然后所有sencha命令都变成“不是内部或外部命令”。解决办法是把 Sencha 的安装目录和工程目录加入杀软的信任列表或排除项再重新解压一份安装包。5.5 老工程报 compass 相关错误老项目的app.json里如果有sass: { generator: compass }这类配置7.0 默认的 fashion 编译器不会接管构建时会尝试调用 Ruby/Compass环境里如果没有就报错。解决方式有两个要么在app.json里把 sass 生成器改成fashion要么老老实实装对应版本的 Ruby然后gem install compass。我更推荐前者毕竟新工具链才是长期方向除非这个工程还有别的地方依赖 compass 的特定行为。最后再分享一个维护老项目的体会版本号别乱升环境变量别乱改下载地址记得存一份。先用 7.0.0.40 把整条链路跑通再考虑升级的事情。很多所谓“框架用不了”的问题并不是框架坏了而是 Cmd 版本和 Ext 版本没配对。我自己维护一个 2019 年的项目到现在靠的就是这套固定的 zip Cmd 组合稳妥省心。本文还有配套的精品资源点击获取