简介面向需要离线部署Superset 4.1.1中文版的企业运维、数据分析人员及Docker学习者该资源将Superset数据可视化工具与容器化部署方式结合解决内网无互联网环境或需要标准化交付场景下的快速搭建问题。压缩包共6个文件包含三个Docker镜像tar包Superset中文版主镜像、PostgreSQL数据库镜像、Redis缓存镜像、docker-compose.yml服务编排、superset_config.py配置以及.env环境变量文件总大小约524.2MB各文件职责明确便于离线导入与二次调整。已有364人学习下载。借助这套离线包无需再手动逐一下载镜像或从零编写编排与配置按docker-compose启动容器即可完成部署同时提供环境变量和配置样例可快速适配数据库连接、端口映射、认证方式等参数。对于希望在内网快速启用Superset进行数据探索与可视化展示的团队这是一份可直接落地的实用方案也能帮助初学者理解容器化部署中各文件的实际作用。1. 离线网络里跑 BISuperset 4.1.1 的 Docker 离线部署为什么绕不开镜像准备在完全断网的内网服务器上交付一个可用的 Apache Superset 4.1.1 中文版 BI 平台难点往往不在 Superset 本身而在离线环境对镜像和依赖的管理方式。没有公网docker pull 用不了apt 装不了pip 也拉不了想把平台做成“开箱即用的中文版”就必须先在一台联网机器上把镜像、配置、语言资源整体梳理好再带进内网。这篇文章会从镜像准备、docker-compose 编排、中文语言包配置到初始化踩坑记录把整个离线部署链路讲完适合正在做内网 BI 交付、信创或政企数据平台的同学参考。2. 离线部署前的准备选型对比与镜像打包的三条命令2.1 先定部署形态单容器只适合试跑交付要上 compose如果你的目标只是本地把 Superset 4.1.1 拉起来看一眼界面docker run -p 8088:8088 apache/superset:4.1.1就够了。但离线交付不一样它要解决三件事重启策略、配置管理、依赖服务。单容器方案里重启策略得靠--restart参数配置要么烧进镜像、要么逐个用-e传外部依赖Redis、元数据库 MySQL还要你自己额外管理。这套东西写进交付文档接收方很难复现后面排障也没有凭据。我通常建议把离线部署直接做成 docker-compose 编排原因是 compose 文件本身就是交付文档。团队拿到文件后一条docker compose up -d能把 Superset、Redis、MySQL 按网络关系起好配置挂载、数据卷、健康检查都写在同一个 YAML 里比单独跑一堆 docker run 命令可靠得多。这里还有一个前置判断内网里有没有已经存在的 MySQL 或 Redis。如果有现成的compose 里就只编排 Superset 一个服务连接串直接指向现成实例如果没有就把这两个依赖一起放进编排文件保证整个栈离线自洽。这个判断结果直接决定后续镜像列表长什么样所以别急着写 compose先把数据库和缓存的情况问清楚。部署方式适合场景离线交付的主要缺点单容器功能验证、临时测试依赖服务要单独维护配置散落docker-compose生产环境交付需要额外准备依赖镜像但一次成型k8s / Helm超大规模集群离线安装整条链路过于复杂交付成本高2.2 在联网机器上准备镜像三条命令完成离线 tar 包离线部署的第一个动作不是部署而是准备镜像。常见做法是找一台可以访问公网的机器用 docker pull 拉取需要的镜像再用 docker save 导出成 tar 文件最后通过 U 盘或内网传输工具拷进目标机器。准备端可以是个人电脑上的 Docker DesktopWindows 或 macOS 都行但如果目标是 Linux/amd64 服务器注意用--platform linux/amd64拉对应架构的镜像避免在 Apple Silicon 的电脑上拉了 arm64 版本导致内网机器跑不起来。需要准备的镜像一般至少有三个Superset 本体、Redis做缓存、MySQL元数据库。如果内网已经有现成的 MySQL 或 Redis只需要拉 apache/superset 一个即可。# 在有公网的机器上执行 docker pull apache/superset:4.1.1 docker pull redis:7.2-alpine docker pull mysql:8.0 # 导出为单文件 tar便于内网拷贝 docker save apache/superset:4.1.1 -o superset-4.1.1.tar docker save redis:7.2-alpine -o redis-7.2.tar docker save mysql:8.0 -o mysql-8.0.tardocker save导出的是镜像的完整分层结构和 manifest包含所有历史层、环境变量、入口点信息常见的错误是用docker export去导容器那个命令只导出容器文件系统会丢掉镜像的层历史和运行元数据加载后起容器往往直接报错这是离线部署里很典型的坑。导出后不要直接把 tar 拷走先记录一下镜像的摘要方便在离线机器上校验。用docker images --digests查看镜像 ID 和 RepoDigest把摘要记录下来或者直接在两台机器上对 tar 包做sha256sum保证拷贝过程没有损坏。离线机器上硬盘空间也要提前预留镜像 tar 解包后实际占用会大于 tar 本身通常建议留出 tar 大小两倍以上的临时空间。2.3 先把 superset_config.py 写对密钥、语言、数据库、缓存四个配置镜像本身不自带生产配置Superset 启动时会去/app/pythonpath/superset_config.py读取自定义配置。离线部署前这个文件在联网准备阶段就要写清楚不然进内网后再改还得反复重建容器。我一般在宿主机上放一份superset_config.py用 volume 挂进容器而不是把配置烧进镜像。原因是以后升级镜像不用重新构建配置单点维护且交付给下一任运维也看得懂。# superset_config.py # 生产模式必须固定 SECRET_KEY否则每次重启会话和签名都会失效 SECRET_KEY please-change-to-a-very-long-random-string # 语言选项只保留英文和简体中文 LANGUAGES { en: {flag: us, name: English}, zh: {flag: cn, name: 简体中文}, } BABEL_DEFAULT_LOCALE zh # 元数据库连接串使用内置 MySQL 服务时主机名写 compose 里的服务名 SQLALCHEMY_DATABASE_URI mysqlpymysql://superset:superset_pwdmysql:3306/superset?charsetutf8mb4 # 结果缓存走 Redis CACHE_CONFIG { CACHE_TYPE: RedisCache, CACHE_KEY_PREFIX: superset_cache, CACHE_REDIS_URL: redis://redis:6379/1, }SECRET_KEY的坑主要在首次初始化前如果启动时没设置Superset 会用随机值初始化Flask 的会话 cookie 和 CSRF 令牌都基于它重启后已登录用户的会话全部失效。运维日志里经常出现“登录后马上被登出”的假象其实只是密钥没固定。LANGUAGES决定界面里可选的语言只有加进去“简体中文”用户切换语言时下拉里才找得到BABEL_DEFAULT_LOCALE则是未登录时默认界面语言把它设成zh内网用户打开页面第一眼就是中文菜单。SQLALCHEMY_DATABASE_URI这里我用的是mysqlpymysql驱动镜像内置了 PyMySQL不需要额外装系统库如果用 PostgreSQL镜像里也自带 psycopg2连接串换成postgresqlpsycopg2://...即可。另外注意charsetutf8mb4不能省。Superset 的元数据里会存中文标签、图表名称、数据集描述如果连接串没指定 utf8mb4MySQL 端默认字符集可能与客户端不一致写入中文时容易出现Incorrect string value一类的报错后面再排查很被动。3. 用 docker-compose 离线启动 Superset编排、初始化与 MySQL 后端切换3.1 compose 文件怎么组织app、Redis、MySQL 三个服务的依赖关系在离线机器上先把之前准备好的 tar 包docker load -i进去然后写 compose。这里给出一个内置 MySQL 和 Redis 的完整编排适用于内网没有任何现成依赖的场景。version: 3.8 services: mysql: image: mysql:8.0 container_name: superset-mysql restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: root_pwd MYSQL_DATABASE: superset MYSQL_USER: superset MYSQL_PASSWORD: superset_pwd command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci volumes: - mysql_data:/var/lib/mysql networks: - superset-net healthcheck: test: [CMD, mysqladmin, ping, -h, localhost] interval: 10s retries: 12 redis: image: redis:7.2-alpine container_name: superset-redis restart: unless-stopped command: redis-server --appendonly yes volumes: - redis_data:/data networks: - superset-net superset: image: apache/superset:4.1.1 container_name: superset restart: unless-stopped ports: - 8088:8088 environment: SUPERSET_SECRET_KEY: please-change-to-a-very-long-random-string volumes: - ./superset_config.py:/app/pythonpath/superset_config.py depends_on: mysql: condition: service_healthy redis: condition: service_started networks: - superset-net networks: superset-net: volumes: mysql_data: redis_data:这里有两个细节值得说明。第一depends_on我特意用了condition: service_healthy否则 MySQL 容器刚起来其实还在初始化Superset 如果先启动第一次db upgrade大概率会碰到“访问数据库连接被拒”的报错日志堆一片新人容易误判成镜像问题。第二compose 默认会给三个服务建一个自定义网络服务名mysql、redis在这个网络里可以被 Superset 容器直接解析所以连接串的主机名写mysql和redis而不是localhost这一点和内网连外部数据库完全不同。镜像加载完成后启动这一步就简单了docker compose up -d docker compose psdocker compose ps要看三个容器状态都是 Up。如果 MySQL 容器反复 restart大概率是初始化 SQL 执行失败或数据卷权限不对先docker logs superset-mysql看 MySQL 自身输出不要急着处理 Superset。3.2 首次初始化必跑的三条命令db upgrade、create-admin、init容器起来后Superset 的元数据库还是空的。官方镜像的入口脚本会在首次启动时尝试初始化一部分基础结构但管理员账号和角色权限仍需要手动执行。离线环境下没有网络加载示例数据集所以load_examples这一步可以直接跳过否则它会去访问外部资源报一堆超时错误。# 把数据库结构升级到当前版本 docker exec -it superset superset db upgrade # 创建管理员账号 docker exec -it superset superset fab create-admin \ --username admin \ --firstname Admin \ --lastname User \ --email adminexample.com \ --password Admin_123456 # 初始化角色、权限和默认配置 docker exec -it superset superset init # 重启一次让配置完整生效 docker restart supersetsuperset db upgrade底层走的是 Alembic 迁移脚本它会在 MySQL 里维护一张alembic_version表记录当前迁移版本。只要这条命令执行成功后面重启容器不会重复迁移。fab create-admin创建的是 Flask-AppBuilder 的管理员也就是登录 Superset 后的超级管理员--password参数如果省略会进入交互模式在自动化脚本里就没法用了。superset init负责初始化权限、采集元数据并构建权限映射。跑完这三条浏览器访问http://内网服务器IP:8088用 admin 账号登录正常情况下已经能进主界面。如果登录后提示CSRF token missing或类似错误多半是 SECRET_KEY 没设或前后配置不一致回 2.3 检查。3.3 为什么离线部署要把元数据库从 SQLite 切到 MySQL官方镜像默认的元数据库连接串是 SQLite文件落在容器内路径/app/superset_home/superset.db。如果只是单机试用SQLite 完全够用但离线部署一旦交给业务方就会遇到几个实际痛点。SQLite 的写锁是库级别的。Superset 的仪表板加载、切片器状态、操作日志都会写元数据库五六个人同时使用很快就会出现database is locked错误。还有备份维度MySQL 可以用mysqldump做逻辑备份也可以在运维侧做主从SQLite 只能靠落盘文件快照在容器环境里很容易备份到容器还在写的那一瞬间而产生坏文件。从升级迁移的角度看SQLite 的坑更明显。以后版本升级Superset 官方只保证 PostgreSQL 和 MySQL 的迁移路径可靠本地文件库经常会碰到 Alembic 迁移卡住的问题。我一直坚持标签为“生产”或“交付”的离线环境一开始就把元数据库放在 MySQL上面的 compose 里保留了 MySQL 容器连接串对应章节 2.3已经提前切好不会出现“部署完才发现要换库”的翻车事故。对比点SQLiteMySQL并发能力库级写锁行级锁多会话备份方式文件快照mysqldump 逻辑备份官方迁移支持较弱迁移路径完善如果是用已有外部 MySQL那连接串要改成宿主机能解析的主机名或 IP不能写mysql因为外部实例不在 compose 网络里第五节专门讲这个网络问题的排查。4. Superset 中文汉化落地语言包、默认语言与字段名映射4.1 语言资源在哪先确认容器里的 translations 目录很多用户看到“中文版”第一反应是找汉化补丁。实际上 Superset 的官方镜像在 4.x 版本中已经内置一套简体中文翻译文件只是默认没被启用。语言资源放在/app/superset/translations/其中中文的编译产物是zh/LC_MESSAGES/messages.moFlask-Babel 在启动时按这个文件加载翻译字符串。离线环境没有网验证镜像里有没有中文资源只有一条路直接在容器内找文件。docker exec -it superset ls /app/superset/translations/ docker exec -it superset find /app/superset/translations/zh -name *.mo如果第二条命令有输出说明翻译文件存在。此时只要superset_config.py里加上了LANGUAGES里的zh界面就能切到中文。如果zh目录缺失或.mo文件不存在常见做法是找一台有网机器拉同一个官方镜像把容器里的 translations 完整拷出来。注意这里拉的是同一个 tag 的镜像不要随意下载第三方整理包。# 在有网机器上执行 docker cp superset:/app/superset/translations ./translations把translations放进离线环境的部署目录再在 compose 里加一条 volume 挂载覆盖镜像内默认路径汉化资源就补上了。# docker-compose.yml 的 superset 服务 volume 里追加 - ./translations:/app/superset/translations这里补一句提醒所谓“中文版”不能只依赖一个 .mo 文件。它至少包含三层语言资源文件.mo、界面默认语言BABEL_DEFAULT_LOCALE、图表与数据集的中文显示名。前两层能在部署阶段解决第三层属于数据建模的日常工作下面两节分开讲。4.2 把默认语言钉死在中文BABEL_DEFAULT_LOCALE 与用户级偏好有了语言资源还要确保用户打开页面时看到的就是中文。这个控制点在两个地方未登录用户看到语言的默认值由superset_config.py里的BABEL_DEFAULT_LOCALE zh决定登录用户的语言偏好存在用户 profile 里打开页面时会优先读它而不是每次都用配置文件里的默认值。所以在部署阶段要做的其实是两步配置文件里把默认语言设为zh然后管理员登录后在右上角头像菜单里把语言切到“简体中文”。如果用户是在英文模式下创建的他看到的还会是英文新用户在注册时语言偏好会继承当前的界面语言所以部署时先切中文再建业务账号顺序上有讲究。BABEL_DEFAULT_LOCALE字段在旧版 Superset 也支持但有些版本对zh的解析依赖语言代码是否存在于LANGUAGES字典。配置里LANGUAGES和BABEL_DEFAULT_LOCALE要同时出现只写一个另一个不会自动生效。改完配置后记得docker restart superset因为 Flask-Babel 的初始化发生在进程启动时不是运行中热加载。时区方面也建议一并处理。Superset 默认使用 UTC中文用户看 “昨天 / 今天” 会差 8 小时。可以在superset_config.py里追加# 让界面和图表时间显示跟随本地时区 TALISMAN_ENABLED False SUPERSET_WEBSERVER_TIMEOUT 120时区的关键修正不在配置文件而是在创建数据源时在数据集属性里选择对应的时区。否则配置了也只会影响服务端日志时间图表横轴时间的偏移要靠数据源时区字段去纠正这一点经常被人忽略。4.3 数据集字段和图表名称中文版的最后一公里部署做完界面是中文了但数据表里的列名还是英文比如created_at、status、user_id。这个阶段的中文化已经从“部署”进入“数据建模”。Superset 里有一个字段叫 verbose_name可以覆盖原始列名。配置入口是数据集编辑页面的 Columns 标签把每个列的 verbose_name 写成中文图表构建时下拉框里、维度名、指标名全部显示中文。如果表只有十几列手工改就行如果是几十张表、上百个字段手工就是体力活用 API 批量更新更稳。REST API 调用的基本步骤是先登录拿 access_token再按数据集 ID 拉取当前列定义修改 verbose_name 后 PUT 回去。一个最小脚本如下# scripts/update_verbose_name.py import requests base_url http://localhost:8088 # 1. 登录拿 token login_resp requests.post(f{base_url}/api/v1/security/login, json{ username: admin, password: Admin_123456, provider: db, refresh: True, }).json() token login_resp[access_token] headers {Authorization: fBearer {token}} # 2. 读取数据集定义ID 从 /api/v1/dataset/ 列表里确认 ds_id 1 resp requests.get(f{base_url}/api/v1/dataset/{ds_id}, headersheaders).json() columns resp[result][columns] # 3. 构造中文字典只改目标字段 name_dict { created_at: 创建时间, updated_at: 更新时间, user_id: 用户ID, status: 状态, } for col in columns: col_name col[column_name] if col_name in name_dict: col[verbose_name] name_dict[col_name] # 4. 写回 requests.put(f{base_url}/api/v1/dataset/{ds_id}, json{columns: columns}, headersheaders)这段脚本的注意点有两个接口返回的columns结构在不同小版本里可能字段名有差异比如 4.x 里列对象的 key 是column_name而 3.x 部分版本是column跑之前先print(columns[0])看一眼结构另外 PUT 请求会把整组列定义覆盖写回去所以脚本里一定要基于 GET 出来的结果修改不能只传想改的那几个字段否则会把其它列的配置冲掉。字段名这种工作可以提前到离线准备阶段做。Superset 的元数据在数据库里提前修改元数据不会影响目标数据源。很多团队把“中文版”做成交付物其实就是把迁移脚本和这份 column 映射表一起放进部署包落地时一次性执行。5. 离线部署避坑记录镜像导入、初始化失败、汉化失效与网络不通5.1 docker load 后镜像显示为 none或 tag 对不上现象离线机器上执行docker load -i superset-4.1.1.tar输出 Loaded但docker images里看到的 tag 是nonecompose 启动时报 “pull access denied for apache/superset”。原因save 时镜像 tag 在 tar 包里其实保留了出现none往往是在有网机器上先改了 tag或者 tar 包传到一半损坏。损坏的 tar 在 load 阶段可能只解出了一部分层完整 tag 没有被覆盖到。解决先校验文件完整性。拷贝前后各执行一次sha256sum superset-4.1.1.tar两边值一样再 loadload 完成后用docker images --digests apache/superset核对 digest而不是只看 tag。如果已经是none状态不需要重新拉镜像直接给镜像打个 tag 即可docker tag 镜像ID apache/superset:4.1.1另外离线机器上如果 docker 服务本身权限不对docker load也会失败或读到不完整内容。内网服务器经常是多人共用的当前用户没加进 docker 组时所有 docker 命令都要加sudo更稳妥的方式是把部署用户加进 docker 组并重新登录一次会话省得后面每条命令都带 sudo也避免 sudo 环境下 volume 路径权限不一致。5.2 初始化命令报错create-admin 用户名已存在或 db upgrade 卡住现象按章节 3.2 执行superset fab create-admin提示Username already exists或者superset db upgrade跑一半报table already exists。常见于同一个 MySQL 库被反复初始化过的场景。原因Superset 的初始化不是完全幂等的。fab create-admin在用户已存在时会直接拒绝不是覆盖密码db upgrade则依赖 Alembic 的 version 表如果之前有人手动建过表但没正确记录版本迁移就会和现存结构冲突。解决内网测试环境最干脆的做法是把元数据库清掉重来比手工修补快得多。用 root 登录 MySQL 容器DROP DATABASE IF EXISTS superset; CREATE DATABASE superset CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; GRANT ALL PRIVILEGES ON superset.* TO superset%; FLUSH PRIVILEGES;然后重新执行docker restart superset-mysql再依次跑superset db upgrade、superset fab create-admin、superset init。这样做之前先确认库里没有业务配置别把仪表板配了半天再清库。如果是生产环境不想清库就要进 MySQL 查看alembic_version表里的 version_num 和 Superset 期望的迁移版本差在哪手工插入或回滚迁移版本但这一步风险较高。我的经验是生产库在第一次初始化前就要定好连接串不要先用 SQLite 跑通再用 MySQL那等于让 Alembic 在同一套迁移脚本上换个数据库重跑很容易踩到已存在表的边界。5.3 界面切到中文后仍有大量英文残留或语言下拉里没有中文现象登录后右上角语言下拉找不到“简体中文”或者切到中文后菜单、设置页仍然大量英文。原因前者说明LANGUAGES字典里根本没把zh加进去后者说明翻译文件缺失或者浏览器缓存了旧的静态资源。还有一个隐蔽原因用户 profile 里的语言偏好在切换后其实已经写入但前端静态资源被本地缓存挡住看起来像“没生效”。解决按顺序排查。先确认配置文件里同时有LANGUAGES和BABEL_DEFAULT_LOCALE然后进入容器确认.mo文件存在docker exec -it superset find /app/superset/translations/zh -name *.mo | head -5文件在的话重启 superset 并清掉 Redis 里的缓存避免旧的翻译缓存影响加载docker exec -it superset-redis redis-cli FLUSHDB docker restart superset浏览器侧强制刷新一次绕过静态资源缓存。如果某几个角落页面仍是英文这多半是该版本的翻译覆盖度问题不属于部署失败可以接受真实生产中没必要为个位数未翻译字符串去改源码重新编译镜像。5.4 容器内连不上同网段 MySQL连接被拒、host 解析不了现象Superset 里配置一个外部 MySQL 数据源测试连接报Cant connect to MySQL server on 192.168.x.x (111 Connection refused)或者报Unknown host mysql。如果数据源是宿主机同网段的 MySQL这类问题在离线环境尤其多。原因两个层面。一是 Superset 容器默认在 compose 网络里容器内的localhost指向它自己不是宿主机连接串写成localhost:3306肯定连不上业务库。二是不管你想连哪个 MySQL那个服务得允许来自容器 IP 的连接MySQL 用户表里 localhost 权限默认只放行回环地址。解决先确认要连的是 compose 网络内的 MySQL还是宿主机所在物理网络的 MySQL连接串按场景区分同一 compose 栈里的 MySQL主机名写mysql端口 3306宿主机上的 MySQL主机名写宿主机局域网 IP而不是localhost其它网段服务器上的 MySQL先在宿主机上用telnet IP 3306验证宿主机到目标库的网络通不通再进容器验证分两步缩小范围。对于外部数据库还要检查目标 MySQL 的bind-address是不是127.0.0.1如果是就要改成0.0.0.0以及 MySQL 用户授权里的 host 段是不是只写了localhost需要改成%或指定内网网段。内网 CentOS 机器如果开了防火墙3306 端口会被 drop现象也是连接超时。还有一个常见误区宿主机上能连库不代表容器里能连。容器网络经过 bridge 和 iptables直接在容器里做连通性测试最直接docker exec -it superset python -c import socket; socket.create_connection((目标IP, 3306), 5)能连上 socket但 Superset 测试连接仍报错那才轮到检查认证和 PyMySQL 驱动层面。6. 部署完先做这三件事健康检查、数据接入验证与配置固化6.1 用健康接口和登录接口验证服务状态离线环境里没有外部技术支持部署完是不是真的能用不能靠“页面出来了”判断要按接口、登录、数据源三层验证。第一层是 Web 健康检查。Superset 暴露了/health接口它只反映 Web 进程是否存活这个返回 200 不代表元数据库和 Redis 都正常curl -s -o /dev/null -w %{http_code}\n http://localhost:8088/health第二层是真实登录与 API 认证。用管理员的账号调/api/v1/security/login拿 token能拿 token 说明配置的 SECRET_KEY、数据库和用户体系都已经可用curl -s -X POST http://localhost:8088/api/v1/security/login \ -H Content-Type: application/json \ -d {username:admin,password:Admin_123456,provider:db,refresh:true}返回 JSON 里带有access_token这步过了登录链路基本没问题。6.2 数据接入与一个真实图表的冒烟自测API 验证完进界面创建一条真实的数据源接一张业务表跑一个汇总图表。别跳过这步直接交付数据源连接是最容易在离线环境里翻车的环节尤其是 5.4 提到的权限和网络问题。我会固定用两类数据源做冒烟测试一类是接入同一个 MySQL 的元数据库验证驱动和基础查询另一类是业务方真实库验证权限、时区和字段映射。后者通常要请业务方提供账号尽量在交付前完成别等到上线当天再碰。6.3 把部署目录固化下来备份元数据库第三层是把部署配置固化下来形成可复现的交付物。我习惯在部署目录里固定放四样东西compose 文件、superset_config.py、translations目录、一份初始化 SQL 和命令的 README。以后升级版本、换机器照着这套流程重新走一遍比到时候从记忆里拼命令可靠得多。升级前记得用 mysqldump 先把元数据库备份出来容器里执行docker exec -i superset-mysql mysqldump -usuperset -psuperset_pwd superset superset_backup_$(date %F).sql备份文件放在部署目录之外另一台机器再放一份。这套“先备份、再 load、再比对 digest、最后才跑迁移”的流程是从一次真实教训换来的。有一次我在升级时图快直接在旧库上跑了新版的superset db upgrade中途连接断掉Alembic 停在中间版本之后怎么迁移都报错最后还是靠之前的 mysqldump 把库还原才救了回来。整个离线部署链路里镜像校验、初始化顺序和汉化配置是最容易出问题的三处也是投入时间最值得的三处。先把这三块按顺序落地再处理数据源的网络连通离线上交付 Superset 4.1.1 中文版就不会有大坑了。希望这些记录能帮到你。本文还有配套的精品资源点击获取