1. 为什么 Ubuntu 18.04 上装 Django 不是“pip install django”就完事了？

你搜到这篇标题时，大概率正卡在某个环节：终端里敲下pip install django后没报错，但一运行django-admin --version就提示 command not found；或者python3 -m django --version能显示版本，可django-admin startproject mysite却报ModuleNotFoundError: No module named 'django'；又或者你刚用sudo apt install python3-django装完，发现版本是 2.2，而你教程里写的asgi.py文件根本不存在——因为那是 Django 3.0+ 才有的东西。

这不是你手速慢，也不是网络抽风。这是 Ubuntu 18.04 这个发行版自带的 Python 生态和现代 Django 开发范式之间，存在三道真实存在的“隐形墙”：

第一道墙叫系统 Python 和用户 Python 的权限撕裂。Ubuntu 18.04 默认把python3绑定在/usr/bin/python3，这个路径下的 Python 是系统级的，由apt包管理器维护。你用sudo pip3 install django，看似装上了，实则把包塞进了系统 Python 的 site-packages 目录（通常是/usr/local/lib/python3.6/dist-packages/）。但 Ubuntu 为了安全，默认禁用了sudo pip3的写入权限——它会悄悄把包装进/root/.local/lib/python3.6/site-packages/，而普通用户 shell 根本找不到这个路径。结果就是：root 能用，你不能用；你pip3 list看不到，python3 -c "import django"却报错。

第二道墙是Python 版本与 Django 版本的代际错配。Ubuntu 18.04 发布于 2018 年 4 月，预装的是 Python 3.6.9。而 Django 4.0 要求 Python ≥3.8，Django 4.2 要求 ≥3.8，Django 5.0 直接要求 ≥3.10。如果你硬要装最新版，pip3 install django==5.0会直接失败，报ERROR: Package 'django' requires a different Python version. 可如果你退而求其次装 Django 3.2（LTS 版本），它又不支持asgi.py中的get_asgi_application()函数——这个函数在 Django 3.0 才引入，而 Ubuntu 18.04 的apt源里只提供 Django 2.2（2019 年发布的 LTS），它连asgi.py文件都没有。你照着官网教程走，第一步就断在manage.py runserver报ImportError: cannot import name 'get_asgi_application'。

第三道墙最隐蔽，叫PATH 环境变量的“幽灵路径”陷阱。django-admin是一个独立的可执行脚本，它不依赖python3 -m django，而是靠系统 PATH 查找。当你用pip3 install --user django，它会把django-admin脚本安装到~/.local/bin/。但 Ubuntu 18.04 的默认 shell 配置（~/.profile）里，只有在~/.local/bin目录存在时，才会自动把它加进 PATH。而很多新手装完--user后没重启 shell，或者用的是zsh却没改~/.zshrc，导致which django-admin返回空，command not found错误就这么来了。它不是没装，是你根本没“看见”。

这三道墙，每一道都对应一个真实、高频、让初学者抓狂的错误代码：

• command 'django-admin' not found
• ModuleNotFoundError: No module named 'django'
• ImportError: cannot import name 'get_asgi_application'
• ERROR: Package 'django' requires a different Python version

它们不是配置错误，是 Ubuntu 18.04 这个“老将”和 Django 这个“新锐框架”在底层设计哲学上的碰撞。解决它，不能靠百度复制粘贴，得理解 Ubuntu 的包管理逻辑、Python 的模块加载机制、以及 Linux 的 PATH 查找规则。接下来，我会带你一层层拆掉这三道墙，不是给你一个能跑的命令，而是给你一套能复用的判断逻辑——下次遇到pip install xxx失败，你知道该先查什么、再改什么、最后验证什么。

提示：本文所有操作均基于 Ubuntu 18.04.6（最终 LTS 版本）实测，Python 版本为 3.6.9。不推荐强行升级系统 Python，那会破坏 Ubuntu 的软件包依赖链，导致apt upgrade失败甚至桌面环境崩溃。我们要做的是“适配”，不是“对抗”。

2. 环境准备：绕过 apt 源陷阱，构建纯净的 Python 工作区

Ubuntu 18.04 的apt源里有两个 Django 相关包：python3-django和python-django（对应 Python 2.7）。前者版本固定为 2.2.12（2021 年 12 月发布的最后一个 2.2.x 补丁），后者早已废弃。直接sudo apt install python3-django看似省事，实则埋下三个长期隐患：

• 版本锁定：apt安装的包无法用pip升级或降级。你想试 Django 3.2？pip3 install django==3.2会报ERROR: Could not install packages due to an EnvironmentError: [Errno 13] Permission denied，因为apt把文件所有权给了 root，pip没权限覆盖。
• 路径污染：apt把 Django 安装在/usr/lib/python3/dist-packages/django/，而pip默认装在/home/username/.local/lib/python3.6/site-packages/django/。当两者共存，Python 的模块搜索顺序（sys.path）可能优先找到旧版，导致import django; print(django.VERSION)输出 2.2.12，而你以为自己装的是 4.2。
• 依赖冲突：Django 2.2 依赖pytz==2019.3，而 Django 4.2 依赖pytz>=2020.1。如果项目同时需要两个版本，apt安装的全局pytz会成为死锁点。

所以，第一步必须“清场”：卸载apt安装的 Django，并确保后续所有操作都在用户空间完成。

2.1 彻底清理 apt 安装的 Django

打开终端，执行以下命令：

sudo apt remove python3-django sudo apt autoremove

autoremove很关键。它会删除python3-django的依赖包，比如python3-pytz、python3-sqlparse。这些包被apt管理，如果不清除，它们会继续留在/usr/lib/python3/dist-packages/下，干扰后续pip安装。

验证是否清理干净：

python3 -c "import django; print(django.__file__)"

如果返回ModuleNotFoundError: No module named 'django'，说明成功。如果返回类似/usr/lib/python3/dist-packages/django/__init__.py的路径，说明还有残留，需手动删除：

sudo rm -rf /usr/lib/python3/dist-packages/django* sudo rm -rf /usr/lib/python3/dist-packages/Django-2.2.12.egg-info

注意：rm -rf命令极其危险，请务必确认路径正确。/usr/lib/python3/dist-packages/下只删以django或Django开头的文件夹和.egg-info文件，其他包（如numpy、requests）绝对不要碰。

2.2 激活用户级 pip，并修复 ~/.local/bin 的 PATH 注册

Ubuntu 18.04 默认已安装pip3，但它可能处于“未激活”状态。检查方法：

pip3 --version

如果报command not found，说明pip3没装。执行：

sudo apt update sudo apt install python3-pip

接着，确保pip3能向用户目录安装包。测试：

pip3 install --user --upgrade pip

这个命令会升级用户级的pip到最新版（Ubuntu 18.04 自带的pip3版本太老，不支持--pre参数，会影响后续安装预发布版）。升级后，pip3 --version应显示pip 23.x或更高。

最关键的一步：让系统“认识”~/.local/bin。Ubuntu 18.04 的~/.profile文件末尾有这样一段注释：

# set PATH so it includes user's private bin if it exists if [ -d "$HOME/.local/bin" ] ; then PATH="$HOME/.local/bin:$PATH" fi

这段代码的意思是：“如果~/.local/bin目录存在，就把它的路径加到 PATH 最前面”。但问题在于：~/.local/bin目录在你第一次用--user安装包之前并不存在。pip3 install --user django会自动创建它，但不会自动触发~/.profile的重载。

所以，我们必须手动创建并注册：

mkdir -p ~/.local/bin echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.profile source ~/.profile

source ~/.profile是关键。它让当前终端立即读取修改后的配置，无需重启。验证是否生效：

echo $PATH | grep ".local.bin"

如果输出中包含/home/yourusername/.local/bin，说明 PATH 已更新。此时，任何用--user安装的可执行脚本（如django-admin）都会被系统识别。

2.3 选择 Python 解释器：为什么不用 pyenv，而用 virtualenv

网上很多教程推荐pyenv来管理 Python 版本。但在 Ubuntu 18.04 上，pyenv的编译安装极其耗时（需build-essential,zlib1g-dev,libssl-dev等十几个依赖），且pyenv install 3.10.0在 18.04 的 GCC 7.5 下会因 OpenSSL 版本不兼容而失败。这不是你的问题，是 Ubuntu 18.04 的基础库太老。

更务实的选择是virtualenv。它不改变系统 Python，而是在用户目录下创建一个完全隔离的 Python 环境副本。这个副本继承系统 Python 的解释器（3.6.9），但拥有独立的site-packages和pip。好处是：

• 安装快：pip3 install virtualenv即可，几秒钟搞定；
• 隔离强：每个项目一个venv，Django 2.2 和 Django 4.2 可以共存，互不干扰；
• 兼容好：virtualenv对 Python 3.6 支持完美，无编译风险。

安装并验证：

pip3 install --user virtualenv virtualenv --version

输出应为20.x.x。至此，你的工作区已准备好：系统 Python 3.6.9 干净，pip3用户级可用，~/.local/bin在 PATH 中，virtualenv已就位。下一步，就是为 Django 选择一个既稳定又不过时的版本。

3. Django 版本选型：在 LTS 稳定性与 ASGI 新特性之间做平衡

Django 的版本策略非常清晰：偶数大版本（2.2, 3.2, 4.2）是 LTS（Long Term Support），提供 3 年安全更新；奇数大版本（3.1, 4.1）是常规版，仅维护 8 个月。Ubuntu 18.04 的生命周期到 2028 年 4 月，这意味着你需要一个能撑到那时的 Django 版本。

我们来横向对比三个候选版本：

结论很明确：Django 3.2 是 Ubuntu 18.04 上的黄金选择。它既是 LTS，又原生支持 ASGI（异步服务器接口），让你能无缝对接uvicorn或daphne，为未来升级打下基础。更重要的是，它对 Python 3.6 的支持是官方保证的，不是“勉强能跑”。

3.1 安装 Django 3.2：精确指定版本，避免意外升级

执行安装命令：

pip3 install --user "Django==3.2.20"

这里用了双引号包裹版本号，是为了防止 shell 把==当作重定向操作符。3.2.20是 Django 3.2 的最后一个安全补丁版本（2023-10 发布），比3.2或3.2.0更可靠。

安装完成后，验证：

django-admin --version # 输出：3.2.20 python3 -c "import django; print(django.VERSION)" # 输出：(3, 2, 20, 'final', 0)

如果django-admin --version报错，说明~/.local/bin没生效，请回看 2.2 节，重新执行source ~/.profile。

3.2 创建项目骨架：理解 manage.py 背后的启动逻辑

现在，用django-admin创建一个标准项目：

django-admin startproject mysite cd mysite ls -l

你会看到：

• manage.py: 项目的命令行入口，它是一个包装脚本，核心是os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')，告诉 Django 去哪里找配置。
• mysite/: 包含__init__.py,settings.py,urls.py,asgi.py,wsgi.py。其中asgi.py是 Django 3.0+ 引入的，内容是：

import os from django.core.asgi import get_asgi_application os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings') application = get_asgi_application()

get_asgi_application()是 ASGI 应用工厂函数，它返回一个符合 ASGI 规范的 callable 对象。而wsgi.py中的get_wsgi_application()是 WSGI 版本，两者并存，由你选择启动方式。

验证项目能否启动：

python3 manage.py runserver

如果看到Starting development server at http://127.0.0.1:8000/，说明 Django 3.2 已成功运行。此时浏览器访问http://127.0.0.1:8000，会看到经典的 Django 欢迎页。

注意：runserver是开发服务器，绝不能用于生产环境。它单线程、无缓存、不处理静态文件，性能极差。生产部署必须用gunicorn+nginx或uvicorn+nginx。

3.3 为什么不用 pip install django（不带版本）？

这是一个新手常犯的“省事”错误。执行pip3 install --user django，pip会安装最新版（当前是 5.0.x）。但如前所述，Django 5.0 要求 Python ≥3.10，而 Ubuntu 18.04 的python3 --version是3.6.9，安装会直接失败：

ERROR: Package 'django' requires a different Python version: 3.6.9 not in '>=3.10'

更隐蔽的问题是，如果你在某个时刻侥幸装上了 Django 4.2（比如你升级了 Python），那么manage.py runserver会报：

ImportError: cannot import name 'get_asgi_application' from 'django.core.asgi'

因为 Django 4.2 的asgi.py里，get_asgi_application()的导入路径变了。它不再从'django.core.asgi'导入，而是从'django.core.handlers.asgi'导入。但你的manage.py是 Django 3.2 生成的，它写死了旧路径。

所以，“精确版本”不是教条，是 Ubuntu 18.04 这个特定环境下的生存法则。它让你的项目从第一天起就具备可预测性、可复现性和可维护性。

4. 实战排错：从 5 个高频报错日志反推故障根源

在 Ubuntu 18.04 上安装 Django，90% 的问题都集中在启动阶段。下面我列出 5 个最典型的报错，每一个都附上完整的排查链路、根因分析和修复方案。这不是罗列解决方案，而是教你如何像一个老手一样，从一行错误日志开始，层层剥茧，定位到真正的病灶。

4.1 报错：Command 'django-admin' not found

完整日志：

$ django-admin --version bash: django-admin: command not found

排查链路：

1. 第一反应：django-admin脚本是否存在？

   ls -l ~/.local/bin/django-admin

   如果返回No such file or directory，说明pip3 install --user django根本没执行，或执行失败（比如网络中断）。重新安装即可。

2. 第二反应：~/.local/bin是否在 PATH 中？

   echo $PATH | tr ':' '\n' | grep local

   如果无输出，说明~/.profile没生效。执行source ~/.profile，再试。

3. 第三反应：django-admin脚本是否损坏？

   head -n 1 ~/.local/bin/django-admin

   正常输出应为#!/usr/bin/env python3。如果是一堆乱码或空文件，说明pip安装过程被中断。执行pip3 uninstall django && pip3 install --user Django==3.2.20彻底重装。

根因总结：这不是 Django 的问题，是 Linux 的 PATH 机制和用户目录权限的组合问题。django-admin是一个符号链接或可执行脚本，它的存在依赖于pip的安装路径和 shell 的环境变量加载顺序。

4.2 报错：ModuleNotFoundError: No module named 'django'

完整日志：

$ python3 -c "import django" Traceback (most recent call last): File "<string>", line 1, in <module> ModuleNotFoundError: No module named 'django'

排查链路：

1. 确认 pip 安装位置：

   pip3 show django

   正常输出应包含Location: /home/username/.local/lib/python3.6/site-packages。如果Location是/usr/local/lib/python3.6/dist-packages，说明你误用了sudo pip3，请按 2.1 节清理。

2. 确认 Python 的模块搜索路径：

   python3 -c "import sys; print('\n'.join(sys.path))"

   检查输出中是否有/home/username/.local/lib/python3.6/site-packages。如果没有，说明pip3 install --user的包没有被 Python 识别。这是因为--user安装的包，其路径是通过site.USER_SITE动态添加的。如果USER_SITE被禁用，就会失效。检查：

   python3 -c "import site; print(site.USER_SITE)"

   如果输出为空，说明site模块被修改。临时修复：

   python3 -c "import site; site.addsitedir('/home/username/.local/lib/python3.6/site-packages')"

3. 终极验证：用python3 -m pip替代pip3

   python3 -m pip install --user Django==3.2.20

   python3 -m pip总是调用与python3解释器绑定的pip，避免了pip3命令本身可能指向错误 Python 版本的风险。

根因总结：Python 的模块加载是路径驱动的。ModuleNotFoundError的本质，永远是sys.path里没有目标模块的路径。排查的核心，就是找出sys.path缺失了哪一段。

4.3 报错：ImportError: cannot import name 'get_asgi_application'

完整日志：

$ python3 manage.py runserver ... File "/home/username/mysite/mysite/asgi.py", line 4, in <module> from django.core.asgi import get_asgi_application ImportError: cannot import name 'get_asgi_application' from 'django.core.asgi'

排查链路：

1. 确认 Django 版本：

   python3 -c "import django; print(django.VERSION)"

   如果输出(2, 2, 12, 'final', 0)，说明你装的是 Django 2.2，而asgi.py是 Django 3.0+ 的产物。解决方案：卸载旧版，安装 3.2。

2. 确认 asgi.py 文件内容：

   cat mysite/mysite/asgi.py

   如果文件里是from django.core.handlers.asgi import get_asgi_application（Django 4.2+ 写法），但你的 Django 是 3.2，就会报错。这是因为manage.py是用旧版 Django 生成的，但你后来升级了 Django。解决方案：删除整个mysite目录，用当前安装的 Django 3.2 重新django-admin startproject mysite。

3. 检查 PYTHONPATH 环境变量：

   echo $PYTHONPATH

   如果输出非空，比如/usr/lib/python3/dist-packages，它会优先于site-packages被搜索，导致加载旧版 Django。临时清除：

   unset PYTHONPATH

根因总结：这是版本不一致引发的“API 断裂”。Django 的内部模块结构随版本演进，get_asgi_application()的位置在 3.2 和 4.2 中不同。manage.py是项目创建时的快照，它记录了当时的 API 调用方式。一旦 Django 升级，manage.py必须重建。

4.4 报错：OSError: [Errno 98] Address already in use

完整日志：

$ python3 manage.py runserver Performing system checks... System check identified no issues (0 silenced). April 05, 2024 - 10:23:45 Django version 3.2.20, using settings 'mysite.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C. Exception happened during processing of request from ('127.0.0.1', 54321) Traceback (most recent call last): ... OSError: [Errno 98] Address already in use

排查链路：

1. 查找占用 8000 端口的进程：

   sudo lsof -i :8000 # 或 sudo netstat -tulpn | grep :8000

   输出类似：

   COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME python3 12345 username 3u IPv4 123456 0t0 TCP *:http-alt (LISTEN)

   PID 是 12345。

2. 杀死进程：

   kill -9 12345

   如果kill -9无效，说明进程是僵尸进程，用sudo pkill -f "runserver"强制结束所有含runserver的 Python 进程。

3. 预防措施：每次启动前，指定一个随机端口：

   python3 manage.py runserver 8001

   或者用--noreload参数禁用自动重载（它有时会 fork 出多个进程）：

   python3 manage.py runserver --noreload

根因总结：Django 的runserver默认监听127.0.0.1:8000。如果你上次没用Ctrl+C正常退出，进程可能还在后台运行，占着端口。这不是 Django 的 bug，是 Linux 进程管理的常态。

4.5 报错：django.core.exceptions.ImproperlyConfigured: Requested setting INSTALLED_APPS, but settings are not configured

完整日志：

$ python3 manage.py migrate ... django.core.exceptions.ImproperlyConfigured: Requested setting INSTALLED_APPS, but settings are not configured

排查链路：

1. 确认 settings.py 是否存在且可读：

   ls -l mysite/mysite/settings.py cat mysite/mysite/settings.py | head -n 5

   如果文件为空或权限为---------，说明创建失败。重新startproject。

2. 确认 DJANGO_SETTINGS_MODULE 环境变量：

   echo $DJANGO_SETTINGS_MODULE

   如果输出mysite.settings，正常。如果为空，Django 不知道去哪找配置。临时设置：

   export DJANGO_SETTINGS_MODULE=mysite.settings

3. 终极验证：在 Python 交互式环境中手动配置：

   python3 >>> import os >>> os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings') >>> import django >>> django.setup() >>> from django.conf import settings >>> print(settings.INSTALLED_APPS)

   如果这一步成功，说明manage.py本身有问题。检查manage.py第 18 行，是否被意外修改。

根因总结：Django 的所有功能都依赖settings模块。这个错误意味着 Django 的配置系统根本没有启动。它通常发生在manage.py被篡改，或项目目录结构被破坏（比如把mysite文件夹重命名了）。

5. 进阶实践：用 virtualenv 构建可复现的生产就绪环境

到此为止，你已经能在 Ubuntu 18.04 上跑起 Django 3.2。但这只是开发起点。真实项目需要更多：数据库驱动、静态文件收集、第三方包管理、环境隔离。virtualenv是这一切的基石。

5.1 创建并激活虚拟环境

进入你的项目根目录（mysite），执行：

python3 -m virtualenv venv source venv/bin/activate

venv/bin/activate是一个 shell 脚本，它会：

• 把venv/bin加到 PATH 最前面，让你的python和pip命令自动指向虚拟环境内的副本；
• 设置VIRTUAL_ENV环境变量，标识当前处于虚拟环境中；
• 修改 shell 提示符，在前面加上(venv)，让你一眼看出状态。

激活后，你的命令行会变成：

(venv) $

此时，which python输出/home/username/mysite/venv/bin/python，which pip输出/home/username/mysite/venv/bin/pip。所有pip install都只会装到venv/lib/python3.6/site-packages/，与系统和其他项目完全隔离。

5.2 在虚拟环境中安装 Django 及生态包

在激活状态下，安装 Django：

pip install "Django==3.2.20"

注意：这里不用--user参数。因为虚拟环境本身就是用户级的，--user会把包装到~/.local，反而破坏了隔离性。

接着，安装常用生态包：

pip install "psycopg2-binary==2.9.5" # PostgreSQL 驱动（如果用 PostgreSQL） pip install "mysqlclient==2.1.1" # MySQL 驱动 pip install "django-crispy-forms==1.14.0" # 表单美化 pip install "django-debug-toolbar==3.8.1" # 开发调试工具

安装完成后，导出依赖清单：

pip freeze > requirements.txt

requirements.txt是一个纯文本文件，内容类似：

Django==3.2.20 asgiref==3.7.2 django-crispy-forms==1.14.0 django-debug-toolbar==3.8.1 pytz==2023.3 sqlparse==0.4.4

这个文件是项目的“DNA”。任何人拿到它，都能用pip install -r requirements.txt一键还原出完全相同的 Python 环境。

5.3 静态文件收集：为生产部署铺路

Django 开发时，静态文件（CSS, JS, 图片）由runserver自动提供。但生产环境（如 nginx）不处理 Python，必须把所有静态文件集中到一个目录，由 Web 服务器直接服务。

首先，在settings.py中配置：

# mysite/mysite/settings.py STATIC_URL = '/static/' STATICFILES_DIRS = [ BASE_DIR / "static", ] STATIC_ROOT = BASE_DIR / "staticfiles"

然后，创建static目录并放一个测试文件：

mkdir static echo "body { background: #f0f0f0; }" > static/style.css

最后，执行收集命令：

python manage.py collectstatic --noinput

--noinput参数跳过确认提示。执行后，staticfiles/目录会被创建，里面包含admin/（Django 自带的后台样式）和你自己的style.css。

验证：

ls -l staticfiles/ # 输出应包含 admin/ 和 style.css

这一步是生产部署的必经之路。collectstatic不是“可选项”，它是 Django 生产就绪的标志性动作。

5.4 数据库迁移：从 SQLite 到 PostgreSQL 的平滑过渡

Django 默认使用 SQLite，适合开发。但生产环境必须用 PostgreSQL 或 MySQL。Ubuntu 18.04 的apt源里有 PostgreSQL 10（LTS 版本），安装只需：

sudo apt install postgresql postgresql-contrib libpq-dev

libpq-dev是psycopg2编译所需的头文件，没有它，pip install psycopg2会失败。

接着，创建数据库和用户：

sudo -u postgres psql # 进入 PostgreSQL 控制台 postgres=# CREATE DATABASE mysite_db; postgres=# CREATE USER mysite_user WITH PASSWORD 'mysecretpassword'; postgres=# ALTER ROLE mysite_user SET client_encoding TO 'utf8'; postgres=# ALTER ROLE mysite_user SET default_transaction_isolation TO 'read committed'; postgres=# ALTER ROLE mysite_user SET timezone TO 'UTC'; postgres=# GRANT ALL PRIVILEGES ON DATABASE mysite_db TO mysite_user; postgres=# \q

然后，在settings.py中修改数据库配置：

# mysite/mysite/settings.py DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': 'mysite_db', 'USER': 'mysite_user', 'PASSWORD': 'mysecretpassword', 'HOST': 'localhost', 'PORT': '5432', } }

最后，执行迁移：

python manage.py makemigrations python manage.py migrate

makemigrations会扫描models.py，生成 SQL 语句；migrate会把这些语句应用到 PostgreSQL 数据库。整个过程对开发者透明，Django 的 ORM 层屏蔽了数据库差异。

提示：psycopg2-binary是预编译的二进制包，安装快，适合开发。生产环境建议用源码编译的psycopg2，性能更好，但需gcc和postgresql-server-dev-10。

6. 最后一课：Ubuntu 18.04 的 Django 生存指南

写到这里，你已经完成了从零到一的全过程：理解了 Ubuntu 18.04 的包管理逻辑，绕过了apt源的版本陷阱，选择了 Django 3.2 这个黄金版本，亲手排掉了 5 个高频报错，并用virtualenv构建了一个可复现、可部署的生产就绪环境。

但我想分享的，不是技术细节，而是我在 Ubuntu 18