企业官网建设流程全解析

Wagtail 部署与托管完全指南：从托管商选择、Fly.io 实战部署到底层基础设施原理

【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtail

本篇技术指南以 Wagtail 官方部署文档为主体，系统讲解三部分内容：如何按服务层级选择合适的托管平台、如何借助 Fly.io + Backblaze B2 完成一次从零到上线的真实部署，以及 Wagtail 托管背后的基础设施原理（WSGI/ASGI、静态文件、用户上传文件、缓存与安全）。读完本文，你将具备独立规划 Wagtail 生产环境、动手部署一个线上站点，并在出问题时定位到对应配置与源码的能力。

部署前的核心认知：Wagtail 即 Django

Wagtail 构建在 Django 之上，因此部署 Wagtail 所需的绝大多数步骤与注意事项，和部署 Django 完全一致。docs/deployment/under_the_hood.md开篇即明确指出这一点，并建议先通读 Django 官方的"How to deploy Django"文档。

换句话说，如果你已经熟悉 Django 生产部署，那么你已经掌握了 Wagtail 部署的 80%；剩下 20% 是 Wagtail 特有的部分——媒体文件（图片/文档）的存储与安全、后台管理界面的静态资源缓存、以及 CMS 特有的审计日志等。本文的 Fly.io 实战章节和"底层原理"章节正是围绕这 20% 展开。

选择托管平台：三级支持模型

Wagtail 官方文档（docs/deployment/index.md）将托管服务商划分为三个层级，按部署难度从低到高排列：

Wagtail 级支持（最容易部署）

官方文档点名了两个提供一等支持（first-class support）的平台：

• CodeRed Cloud（codered.cloud）：官方描述强调"极简、开箱即用（it just works）"理念，无需特殊包或第三方服务；免费套餐可用，且每个套餐都包含数据库、媒体托管和每日备份。
• Divio（divio.com）：面向容器化 Web 应用的云托管平台，与 Wagtail 集成顺畅，提供自动化备份、预发（staging）环境等能力，官方声明其平台可确保 Wagtail 应用的可扩展性、安全性与可靠性。

选择此类平台时，你几乎可以把全部精力放在业务开发上，数据库、媒体存储、备份等运维负担由平台承担。

Python 级支持（需要部分基础设施知识）

这类平台将 Python 运行环境作为服务提供，典型代表是Fly.io。官方为此专门撰写了完整的部署教程（Fly.io + Backblaze 部署教程）。使用这类平台，你通常需要自行配置：

1. 一个 WSGI 服务器（如 Gunicorn）来处理 Django 应用请求；
2. 媒体文件的存储方案（例如对象存储服务）；
3. 一个数据库（例如 Fly Postgres）。

基础设施级支持（需要 Linux 知识）

这类服务商只提供运行 Linux 服务器、数据库、文件存储所需的底层工具，常见的包括AWS、Azure、Digital Ocean、Google Cloud、Linode。所有服务器配置、进程管理、反向代理、防火墙等工作都需要你亲自完成，灵活性最高，但部署成本也最高。

其他参考

官方还指出，部分第三方平台上的部署实例可在 docs/advanced_topics/third_party_tutorials.md 中查看；这并非 Wagtail 可运行平台的完整清单，也不代表官方推荐的唯一方式。若要进行托管的底层技术深潜，请看本文后半部分对应的"底层原理"内容。

实战部署：Fly.io + Backblaze B2 完整教程

接下来，我们完整走一遍 docs/deployment/flyio.md 提供的生产部署流程。思路是：站点本体托管在 Fly.io，图片等媒体文件存放在 Backblaze B2 对象存储。将图片与站点分离的好处是更好的性能、安全性与可靠性——对象存储由专业 CDN 网络分发，且不占用应用服务器资源。

注意：教程中反复出现的yourname占位符，请替换为你自己选择的名称。

第一步：注册 Backblaze B2 云存储

1. 在浏览器访问 Backblaze 官网，顶部导航点击Products，在下拉菜单中选择B2 Cloud Storage；
2. 注册账户：输入邮箱与密码、选择合适的区域（Region）、点击Sign Up Now；
3. 验证邮箱：进入Account > My Settings，在 Security 区域点击Verify Email，输入注册邮箱并获取验证码，然后点击邮件中的验证链接或输入验证码；
4. 创建存储桶（Bucket）：进入B2 Cloud Storage > Bucket，点击Create a Bucket，按下表填写信息：

5. 点击Create a Bucket完成创建。

第二步：将站点链接到 Backblaze B2

在项目根目录创建.env.production文件。此时你的项目目录结构大致如下（以官方教程中的 portfolio 站点为例）：

mysite/ ├── base ├── blog ├── home ├── media ├── mysite ├── portfolio ├── search ├── .dockerignore ├── .gitignore ├── .env.production ├── Dockerfile ├── manage.py ├── mysite/ └── requirements.txt

然后在.env.production中写入以下环境变量：

AWS_STORAGE_BUCKET_NAME= AWS_S3_ENDPOINT_URL=https:// AWS_S3_REGION_NAME= AWS_S3_ACCESS_KEY_ID= AWS_S3_SECRET_ACCESS_KEY= DJANGO_ALLOWED_HOSTS= DJANGO_CSRF_TRUSTED_ORIGINS=https:// DJANGO_SETTINGS_MODULE=mysite.settings.production

用 Backblaze B2 桶信息填充变量

为什么变量名都是AWS_前缀？因为 Backblaze B2 提供了与 Amazon S3 兼容的 API（S3-compatible），django-storages 的 S3 后端可以直接对接，所以沿用 AWS 命名习惯。

创建 Application Key 获取密钥

上表中AWS_S3_ACCESS_KEY_ID与AWS_S3_SECRET_ACCESS_KEY需要去 Backblaze 控制台生成：

1. 登录 Backblaze B2 账户，进入Account > Application Keys；
2. 点击Add a New Application Key，按下表配置：

3. 点击Create New Key；
4. 生成后，将keyID填入AWS_S3_ACCESS_KEY_ID，将applicationKey填入AWS_S3_SECRET_ACCESS_KEY。

此时.env.production的内容应为：

AWS_STORAGE_BUCKET_NAME=yourname-wagtail-portfolio AWS_S3_ENDPOINT_URL=https://s3.us-east-005.backblazeb2.com AWS_S3_REGION_NAME=us-east-005 AWS_S3_ACCESS_KEY_ID=your Backblaze keyID AWS_S3_SECRET_ACCESS_KEY=your Backblaze applicationKey DJANGO_ALLOWED_HOSTS= DJANGO_CSRF_TRUSTED_ORIGINS=https:// DJANGO_SETTINGS_MODULE=mysite.settings.production

安全警示（重要）：.env.production包含访问站点的凭据，绝不能提交到版本库或分享给他人；如果遗失了 secret application key，按前述步骤重新生成一把新密钥即可。

第三步：注册并配置 Fly.io

1. 在浏览器访问 Fly.io，点击Sign Up，可使用 GitHub、Google 或邮箱注册；
2. 查收邮箱中的验证链接完成验证。若验证失败，可前往 Fly.io Dashboard 重试；
3. 进入Dashboard > Billing，点击Add credit card添加信用卡。官方说明强调：添加信用卡只是创建项目的必要条件，Fly.io 不会在添加后立刻扣费；
4. 安装 flyctl 命令行工具，按操作系统选择：

macOS（Homebrew 或官方脚本）：

# 已安装 Homebrew 时： brew install flyctl # 未安装 Homebrew 时： curl -L https://fly.io/install.sh | sh

Linux：

curl -L https://fly.io/install.sh | sh

Windows（PowerShell）：

pwsh -Command "iwr https://fly.io/install.ps1 -useb | iex"

若 Windows 提示pwsh不是可识别的命令，先安装 PowerShell MSI，再重跑上面的命令。若安装后提示fly无法识别或flyctl: command not found，需要把 flyctl 加入 PATH。

5. 登录 Fly.io：

fly auth login

若使用微软 WSL，需先执行：

ln -s /usr/bin/wslview /usr/local/bin/xdg-open

6. 创建项目：运行fly launch，然后按提示输入y配置设置；
7. 浏览器会打开 Fly.io 管理界面，按下表填写：

点击Confirm settings确认。

注意：建议在fly launch时就通过 Web 界面一并创建数据库；若不与应用一起创建，会导致应用与数据库未建立连接。若后续再次运行fly launch，同样推荐通过 Web UI 随应用一起新建数据库。

8. 回到终端，回答提示问题：

fly launch会在项目目录生成两个新文件：Dockerfile和fly.toml。

如果使用 VS Code 等第三方终端创建 Postgres 数据库时报错，可先删除项目中的fly.toml，然后在浏览器中进入 Dashboard，逐个删除 Apps 列表中的应用（Settings > Delete app），最后在系统内置终端或 PowerShell MSI 中重新运行fly launch。

第四步：定制站点以适配 Fly.io

忽略敏感文件

在.gitignore中加入：

.env*

在.dockerignore中加入（让 Docker 忽略环境文件与本地媒体文件）：

.env* media

将 Gunicorn worker 数调整为 1

Fly.io 免费档内存较小，将 worker 数设为 1 可以让站点更好地适配低内存配额。修改Dockerfile最后一行：

CMD ["gunicorn", "--bind", ":8000", "--workers", "1", "mysite.wsgi"]

检查fly.toml

确认其中包含数据库迁移的 release 命令：

[deploy] release_command = "python manage.py migrate --noinput"

完整的fly.toml应类似：

app = "yourname-wagtail-portfolio" primary_region = "lhr" console_command = "/code/manage.py shell" [build] # add the deploy command: [deploy] release_command = "python manage.py migrate --noinput" [env] PORT = "8000" [http_service] internal_port = 8000 force_https = true auto_stop_machines = true auto_start_machines = true min_machines_running = 0 processes = ["app"] [[statics]] guest_path = "/code/static" url_prefix = "/static/"

更新生产依赖

用下面的内容替换requirements.txt：

Django>=4.2,<4.3 wagtail==5.1.1 gunicorn>=21.2.0,<22.0.0 psycopg[binary]>=3.1.10,<3.2.0 dj-database-url>=2.1.0,<3.0.0 whitenoise>=5.0,<5.1 django-storages[s3]>=1.14.0,<2.0.0

各依赖在生产环境中的作用：

注：该教程示例的版本号针对当时的 Wagtail 5.1 编写；当前仓库版本为 8.1（见 wagtail/init.py）。实际部署时请以官方发布版本为准选择兼容的版本组合，仓库自带的 project_template/requirements.txt 与 project_template/Dockerfile 也提供了官方维护的最新依赖与多阶段构建参考。

编写生产环境设置文件

用以下内容替换mysite/settings/production.py：

import os import random import string import dj_database_url from .base import * DEBUG = False DATABASES = { "default": dj_database_url.config(conn_max_age=600, conn_health_checks=True) } SECRET_KEY = os.environ["SECRET_KEY"] SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https") SECURE_SSL_REDIRECT = True ALLOWED_HOSTS = os.getenv("DJANGO_ALLOWED_HOSTS", "*").split(",") CSRF_TRUSTED_ORIGINS = os.getenv("DJANGO_CSRF_TRUSTED_ORIGINS", "").split(",") EMAIL_BACKEND = "django.core.mail.backends.console.EmailBackend" MIDDLEWARE.append("whitenoise.middleware.WhiteNoiseMiddleware") STORAGES["staticfiles"]["BACKEND"] = ( "whitenoise.storage.CompressedManifestStaticFilesStorage" ) if "AWS_STORAGE_BUCKET_NAME" in os.environ: AWS_STORAGE_BUCKET_NAME = os.getenv("AWS_STORAGE_BUCKET_NAME") AWS_S3_REGION_NAME = os.getenv("AWS_S3_REGION_NAME") AWS_S3_ENDPOINT_URL = os.getenv("AWS_S3_ENDPOINT_URL") AWS_S3_ACCESS_KEY_ID = os.getenv("AWS_S3_ACCESS_KEY_ID") AWS_S3_SECRET_ACCESS_KEY = os.getenv("AWS_S3_SECRET_ACCESS_KEY") INSTALLED_APPS.append("storages") STORAGES["default"]["BACKEND"] = "storages.backends.s3boto3.S3Boto3Storage" AWS_S3_OBJECT_PARAMETERS = { "CacheControl": "max-age=86400", } LOGGING = { "version": 1, "disable_existing_loggers": False, "handlers": { "console": { "class": "logging.StreamHandler", }, }, "loggers": { "django": { "handlers": ["console"], "level": os.getenv("DJANGO_LOG_LEVEL", "INFO"), }, }, } WAGTAIL_REDIRECTS_FILE_STORAGE = "cache" try: from .local import * except ImportError: pass

代码要点逐条解析：

1. DEBUG = False：关闭调试模式，生产环境安全与性能的关键；
2. SECRET_KEY = os.environ["SECRET_KEY"]：从环境变量读取项目密钥（务必通过flyctl secrets注入，不要硬编码）；
3. SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")：当站点部署在反向代理（如 Fly.io 的 HTTPS 边缘）之后时，让 Django 正确识别安全连接；
4. SECURE_SSL_REDIRECT = True：强制 HTTPS 重定向，保证所有连接加密；
5. ALLOWED_HOSTS = os.getenv("DJANGO_ALLOWED_HOSTS", "*").split(",")：定义可访问站点的主机名列表，从环境变量读取，未设置时默认放行所有主机；
6. EMAIL_BACKEND = "django.core.mail.backends.console.EmailBackend"：使用控制台邮件后端（生产可替换为真实邮件服务）；
7. WAGTAIL_REDIRECTS_FILE_STORAGE = "cache"：将 Wagtail 重定向的文件存储配置为使用缓存（Wagtail 5.x 时代的旧配置项；在新版本中重定向已改用数据库存储，部署时以当前版本文档为准）。

关于STORAGES的说明：STORAGES["staticfiles"]["BACKEND"]换成了 WhiteNoise 的压缩清单存储后端，让静态文件带哈希文件名、由 Whitenoise 直接提供服务；而STORAGES["default"]["BACKEND"]在检测到AWS_STORAGE_BUCKET_NAME环境变量后切换为storages.backends.s3boto3.S3Boto3Storage，使上传的图片与文档落盘到 Backblaze B2。

补齐环境变量并注入密钥

最终.env.production内容如下：

AWS_STORAGE_BUCKET_NAME=yourname-wagtail-portfolio AWS_S3_ENDPOINT_URL=https://s3.us-east-005.backblazeb2.com AWS_S3_REGION_NAME=us-east-005 AWS_S3_ACCESS_KEY_ID=your Backblaze keyID AWS_S3_SECRET_ACCESS_KEY=your Backblaze applicationKey DJANGO_ALLOWED_HOSTS=yourname-wagtail-portfolio.fly.dev DJANGO_CSRF_TRUSTED_ORIGINS=https://yourname-wagtail-portfolio.fly.dev DJANGO_SETTINGS_MODULE=mysite.settings.production

将环境变量作为密钥导入 Fly.io：

flyctl secrets import < .env.production

Windows（PowerShell MSI）：

Get-Content .env.production | flyctl secrets import

第五步：部署上线

执行部署命令：

fly deploy --ha=false

--ha=false的含义：默认fly deploy会为应用创建两台机器（高可用）；加上该参数后只创建一台机器，符合免费额度的资源预算。

部署完成后，站点即已上线。接下来为线上站点创建管理员用户：

flyctl ssh console

然后在容器内执行：

DJANGO_SUPERUSER_USERNAME=username DJANGO_SUPERUSER_EMAIL=mail@example.com DJANGO_SUPERUSER_PASSWORD=password python manage.py createsuperuser --noinput

请将username、mail@example.com、password替换为你自己的用户名、邮箱与密码。

第六步：为线上站点添加内容

线上环境与本地环境是相互独立的，之前在本地产出的内容不会自动同步。访问https://yourname-wagtail-portfolio.fly.dev/admin/，登录后即可通过后台为线上站点添加内容，包括首页内容、社交媒体链接、页脚文本、站点菜单页面、联系信息与简历等（对应 docs/tutorial 系列教程的各小节）。

若访问线上站点报错，可前往 Fly.io Dashboard 查看应用日志：Dashboard > Apps > yourname-wagtail-portfolio > Monitoring。

深入原理：Wagtail 托管底层基础设施

如果上面的实战教程解决了"怎么部署"，那么 docs/deployment/under_the_hood.md 解决的是"为什么这样部署"。以下内容适合已经了解基本部署流程、希望掌握原理的读者。

WSGI / ASGI 服务器

Django 是 Web 框架，必须依托 Web 服务器运行；而大多数 Web 服务器并不原生"讲" Python，因此需要 WSGI/ASGI 这样的接口协议来完成通信。Wagtail 同时支持 WSGI 与 ASGI 两种方式部署，但Wagtail 自身并未实现任何异步视图或异步中间件，因此官方推荐使用 WSGI。

这也是为什么上面的 Fly.io 教程选用 Gunicorn（gunicorn --bind :8000 mysite.wsgi）作为应用服务器。仓库自带的 project_template/Dockerfile 同样以 Gunicorn 作为最终运行命令（gunicorn {{ project_name }}.wsgi:application），并给出了多阶段构建的官方参考实现：builder 阶段编译依赖、runtime 阶段以非 root 的wagtail用户运行、EXPOSE 8000、容器启动时先执行migrate再启动 Gunicorn。

静态文件：生产环境必须单独处理

与所有 Django 项目一样，静态文件只在开发环境由manage.py runserver负责提供；生产环境中必须在 Web 服务器层面另行处理。

Wagtail 后台的 JavaScript 与 CSS 文件在每个版本之间变化频繁，如果浏览器或服务器缓存了旧版本，会引发难以排查的诡异问题。因此官方强烈建议在生产环境的STORAGES["staticfiles"]设置中启用ManifestStaticFilesStorage——它会给不同版本的文件分配带内容哈希的独立 URL，从而彻底规避缓存串号问题。

仓库自带的项目模板 wagtail/project_template/project_name/settings/production.py 正是这样做的：

DEBUG = False # ManifestStaticFilesStorage is recommended in production, to prevent # outdated JavaScript / CSS assets being served from cache # (e.g. after a Wagtail upgrade). STORAGES["staticfiles"]["BACKEND"] = "django.contrib.staticfiles.storage.ManifestStaticFilesStorage" try: from .local import * except ImportError: pass

模板中的基础设置（wagtail/project_template/project_name/settings/base.py）则定义了STATIC_URL = "/static/"、STATIC_ROOT、MEDIA_ROOT = BASE_DIR / "media"、MEDIA_URL = "/media/"等路径，并显式声明STORAGES默认后端为FileSystemStorage——生产部署时再按需覆盖为 Manifest 存储或云存储。

用户上传文件：图片与文档

Wagtail 遵循 Django 管理上传文件的惯例（Django 文件处理文档）。默认情况下，Wagtail 使用 Django 内置的FileSystemStorage，把文件存放到由MEDIA_ROOT指定的服务器本地目录；也可以通过STORAGES["default"]设置配合 django-storages 等第三方包，将图片与文档存储到 Amazon S3 等云存储服务——这正是 Fly.io 教程中通过S3Boto3Storage对接 Backblaze B2 的原理所在。

安全总则

任何允许用户上传文件的系统都存在安全风险。例如，有上传权限的用户若上传了包含脚本的 HTML 文件，当其他用户直接浏览该文件时可能触发跨站脚本攻击（XSS）。如果所有能访问 Wagtail 后台的人都是完全可信的（例如只有你一个编辑的个人站点），风险可控；但 Wagtail 默认提供安全配置，开发者若想放开限制，必须充分理解风险。

图片的安全与分发

• 使用FileSystemStorage时，图片 URL 从MEDIA_URL指定的路径构造。大多数情况下，应当让 Web 服务器直接从MEDIA_ROOT下的images子目录提供图片（不经过 Django/Wagtail），并屏蔽original_images子目录的访问。
• 如果启用了 SVG 图片（见 docs/topics/images.md），用户可能上传包含脚本的 SVG 文件，直接浏览时会执行其中的脚本；官方针对这一风险提供了多种规避方案。
• 使用云存储后端时，图片 URL 直接指向云存储地址。如果想从独立的资源服务器或 CDN 提供图片，可以配置图片 serve 视图的 redirect 动作，让图片请求 302 重定向到资源地址（参见 docs/advanced_topics/images/image_serve_view.md）。

文档的三种服务方式：WAGTAILDOCS_SERVE_METHOD

文档（Document）的服务方式由WAGTAILDOCS_SERVE_METHOD设置控制（完整说明见 docs/reference/settings.md）。正常情况下，文档请求会经过一个 Django 视图执行隐私检查（如集合的 Privacy 设置）与访问计数等内务操作；但由 Django 服务器代为传输文件会带来性能开销，尤其会抵消把文档托管到 S3/CDN 的大部分收益。为此 Wagtail 提供了三种在"权限检查严格度"与"性能"之间取舍的服务方法：

如果该设置未指定或为None，默认规则是：使用远程存储后端（暴露 URL 但不暴露本地文件路径）时为'redirect'，否则为'serve_view'。

这一逻辑在源码中有清晰的对应实现：在 wagtail/documents/views/serve.py 中，serve视图首先校验document_id与文件名匹配、依次触发before_serve_document钩子并发送document_served信号，然后根据WAGTAILDOCS_SERVE_METHOD决定是直接 302 重定向到doc.file.url，还是走serve_local流程（本地路径用sendfile、远程存储用FileResponse流式传输），并在响应头附加Content-Security-Policy: default-src 'none'与X-Content-Type-Options: nosniff等安全头。相关行为在 wagtail/documents/tests/test_views.py 中有系统测试覆盖。

与文档安全相关的配套设置还包括：

• WAGTAILDOCS_CONTENT_TYPES：指定serve_view方式下各扩展名返回的 MIME 类型（未列出的用 Pythonmimetypes.guess_type猜测，失败则回退application/octet-stream）；
• WAGTAILDOCS_INLINE_CONTENT_TYPES：列出以Content-Disposition: inline内联展示而非下载的 MIME 类型列表，默认application/pdf；
• WAGTAILDOCS_BLOCK_EMBEDDED_CONTENT：默认True，为文档返回限制性 CSP，阻止内嵌内容（如 HTML 文件中的脚本）执行，官方强烈建议保持默认。

云存储的真相：并未完全卸载文件处理

需要注意，配置远程存储并不会把文件处理任务完全卸载给对象存储：某些 Wagtail 功能仍要求应用服务器回读文件。最典型的是——每当创建新的缩放版本（rendition）时，应用服务器必须回读原始图片文件；文档若配置为经 Django 视图服务以执行权限检查，同样需要回读。

重要警告：django-storages 的 Amazon S3 后端（storages.backends.s3boto.S3BotoStorage与storages.backends.s3boto3.S3Boto3Storage）在默认配置下不能正确处理重名文件。使用这些后端时，必须将AWS_S3_FILE_OVERWRITE设为False，否则文件名冲突可能导致文件被意外覆盖。

缓存：加速后台的关键

Wagtail 设计上会利用 Django 的缓存框架来加速页面加载，缓存对Wagtail 后台尤其有价值——后台无法借助常规 CDN 缓存。Wagtail 支持 Django 的全部缓存后端，但官方不建议使用与运行进程/环境绑定的缓存（如FileBasedCache或LocMemCache），因为它们在不同进程/实例之间不共享、无法支撑多实例部署。

部署技巧清单

官方没有"唯一正确"的部署方式，但给出了若干让站点更稳定、更可维护的建议：

1. 执行 Django 部署检查清单：Django 官方提供了一份部署 checklist（django-admin check --deploy），覆盖上线前应完成或至少知晓的所有事项，建议逐项过一遍。

2. 日志与监控（logging and monitoring）：生产环境通常需要多层日志与指标。Wagtail 本身贡献两样东西：

   • 审计日志（audit log）：记录创建、编辑、删除、发布、移动等敏感 CMS 操作，详见 docs/extending/audit_log.md；
   • 标准 Django 日志：通过 DjangoLOGGING设置记录请求错误与表单校验失败。

   常见的外部补充包括：错误与性能监控（对 Django 应用做运行时插桩）、Web 服务器/反向代理/CDN 日志（关注请求量、状态码与限流）、Web 应用防火墙（WAF）日志（用于攻击模式检测）。

3. 性能优化：生产站点应尽可能快，官方性能建议见 docs/advanced_topics/performance.md。

总结：一次部署，两种视角

本文以官方部署文档为主线，给出了完整的行动路径：先按三级支持模型选定托管平台，再以 Fly.io + Backblaze B2 为例完成从对象存储、环境变量、容器配置到fly deploy的全流程实战，最后以 WSGI 服务器、静态文件、上传文件与缓存为切入点理解底层原理。

部署 Wagtail 站点的核心心智模型可以浓缩为三句话：

• Wagtail 是 Django，Django 部署的成熟经验（WSGI、数据库、环境变量、部署检查清单）全部适用；
• 静态文件与媒体文件要分开对待：静态文件交给 Manifest 存储 + Whitenoise/CDN，用户上传文件按图片、文档分别设计存储与安全策略（WAGTAILDOCS_SERVE_METHOD是文档服务的总开关）；
• 安全默认从严：DEBUG=False、密钥走环境变量、HTTPS 强制、上传文件按"不可信输入"对待，是任何生产部署都不可妥协的底线。

如果你在某个特定平台上完成了部署并积累了经验，Wagtail 官方也欢迎将部署笔记贡献回文档，让社区受益。

【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtail