企业官网建设流程全解析

说实话，我每次带新人上手Django时，都能在“创建项目”这个阶段收到一堆同样的报错截图。有人卡在命令找不到，有人装完库后一启动就飘红，还有人在PyCharm里折腾半天才跑通一个hello world。你搜索记录的这些关键词——创建app、PyCharm导入项目、安装Django，其实背后全是同一个问题：新建Django项目的环境与环节没有理顺。

这篇就按我实操踩坑的顺序，把从装环境到成功启动页面的所有坑位过一遍。不聊概念解读，不讲抽象架构，全部是对着控制台和PyCharm界面能直接操作的内容，附带报错原因与排查方法。准备开始之前先放一句经验结论：Django项目创建期的问题，大概率不是你代码写错，而是环境版本、路径配置和操作顺序这三件事没对齐。

1. 环境准备阶段：装Django之前先解决版本和虚拟环境

1.1 Python与Django的版本匹配，不是你选了最新就万事大吉

新手最容易踩的第一个坑，就是装了个最新版Python，再装一个最新版Django，然后项目跑到一半突然报语法兼容错误。我见过最典型的是Python 3.12刚发布那阵，有人直接pip install django装上5.2，结果第三方库在迁移时报unsupported operand type。

这里有个简单对照逻辑：Django每个大版本都会写明支持的Python版本范围。比如Django 4.2 LTS支持Python 3.8到3.12，Django 5.0以上要求Python 3.10起步。你如果Python版本偏老，被Django拒绝；如果Python版本太新但Django还是旧版，也会有兼容问题。建议直接查官方Supported Versions表格，用版本范围中间的稳定组合，比如Python 3.10配Django 4.2 LTS，这个组合在目前兼容性最稳。

判断当前环境版本也非常重要。控制台里输入：

python --version pip show django

1.2 不建虚拟环境就开干，等于给后续埋雷

我知道很多新手嫌麻烦，直接在全局Python环境里pip install django，然后开始写项目。短期看没问题，但只要你开始做第二个、第三个项目，依赖冲突就会找上门：一个项目要用Django 3.2，另一个项目要Django 5.1，全局环境只有一个，你装来装去最后全乱套。

虚拟环境本质上就是个隔离的Python包仓库。类似给每个项目单独配一个干净的抽屉，互不干扰。创建虚拟环境的标准操作：

python -m venv venv

Windows下激活命令：

venv\Scripts\activate

macOS/Linux下激活命令：

source venv/bin/activate

激活后终端命令行前面会出现(venv)字样，这时候你pip安装的任何包都只进这个抽屉。新手容易忘的是激活这一步，没激活就装包，装到全局了，项目里import不到，然后反复报ModuleNotFoundError。

装依赖这件事，我强烈建议从一开始就用requirements.txt管理。项目刚创建还没有依赖时可以先空着，后面每安装一个包就顺手写进去：

pip freeze > requirements.txt

这个习惯的成本极低，但在换电脑、换环境的时候能省下一个下午。

1.3 pip安装Django总是失败的三个原因

安装命令本身很简单：

pip install django==4.2.16

我刻意带上了版本号，原因后面说。如果你安装过程中遇到ReadTimeoutError、ConnectionError之类的报错，绝大多数情况是网络连接问题。处理方法是换国内镜像源，用清华源举例：

pip install django -i https://pypi.tuna.tsinghua.edu.cn/simple

如果你是Linux或macOS用户，还可能在pip install的时候撞上一个Externally-Managed-Environment报错，这是新版Python的PEP 668机制保护系统环境做的限制，意味着你直接用系统Python装包被拦了。解决办法就是回到1.2，先建虚拟环境再装。

另一个要注意的细节是pip和python的对应关系。有些机器上存在多版本Python，python命令指3.8，pip命令指3.11，你python -m venv建了一个3.8的环境，却用pip装包，可能装了3.11的位置，项目还是说找不到Django。为了保险，建议用python -m pip install django来执行安装，确保装进当前解释器对应的pip里。

安装完成后的验证，我习惯用一条命令确认版本：

python -c "import django; print(django.get_version())"

能输出版本号就是环境OK。如果这里报错，就不要往下走了，回去检查虚拟环境和pip，否则后面每一步都不顺。

1.4 关于“用AI Agent辅助开发Django”的那点事

热词里我看到一个“用AI agent开发Django”，顺带说两句。AI辅助写Django代码确实能提速，尤其是重复性的视图函数、模型字段这类样板代码。但我还是要泼一盆冷水：AI生成的代码在“创建项目”这个阶段帮不上什么忙，因为环境、路径、依赖这类问题AI看不见你终端窗口的真实状态，它只能给你通用答案，而通用答案往往恰恰是你在网上已经搜过无数遍的那种。

我的建议是，AI可以帮你写业务代码，但环境搭建和基础配置必须自己理解。否则项目一旦运行不起来，你连报错信息都看不懂，那比不用AI还痛苦。等你能熟练处理创建期的各类报错后，再用AI Agent来批量生成CRUD代码，会顺手得多。

2. 项目创建阶段：第一条命令就开始飘红怎么办

2.1 django-admin命令找不到？用python -m django替代

项目创建的标准命令是：

django-admin startproject mysite

但新手经常碰到的报错是django-admin: command not found，Windows下则是'django-admin' 不是内部或外部命令。原因主要有两种：一是虚拟环境没有激活，django-admin脚本所在的Scripts目录不在PATH里；二是安装Django时脚本没有正确写入环境变量。

不用去折腾PATH环境变量，有个稳到不会出错的替代方案：

python -m django startproject mysite

python -m的含义是让Python以模块方式运行django包，只要当前解释器能import到django，命令就一定有效。你只需要确认虚拟环境激活了（命令行开头有(venv)），这个命令百分百能跑通。

补充一个判断技巧：如果python -m django --version能输出版本号，而django-admin --version报错，说明Scripts目录不在PATH里，别管它，以后都用python -m django形式就行。

2.2 项目目录结构别搞错，这决定了你后续所有路径

执行完startproject后，你会在当前文件夹下看到这样的结构：

mysite/ ├── manage.py └── mysite/ ├── __init__.py ├── settings.py ├── urls.py ├── asgi.py └── wsgi.py

这个结构很经典：外层mysite是项目容器（或者说工作目录），内层mysite是配置包。很多人在创建时手一抖，在已经存在的mysite文件夹里又创建了一个mysite，然后路径就变成三层套娃。这虽然不影响运行，但后面配置PyCharm、配置部署的时候路径会非常容易搞错。

还有个常见问题是把项目建在了某个深层目录或者中文路径下。Django对中文路径的支持以前有坑，虽然新版好了很多，但为了保险起见，项目路径建议全英文无空格。

创建好后马上验证一下：

python manage.py runserver

正常情况你会看到Starting development server at http://127.0.0.1:8000/。浏览器打开这个地址出现火箭页面，项目创建就成功了。

如果端口被占用——这在你开着其他服务时特别常见——控制台会报Error: That port is already in use，换个端口就行：

python manage.py runserver 8001

2.3 settings.py这些配置项创建后立刻就要改

项目创建后默认的settings.py是Django标配，但有几个地方我建议第一时间修改，不然很快会在后面踩坑。

ALLOWED_HOSTS在开发阶段保持默认空列表就行。但如果你要用手机访问或者局域网里其他设备访问跑在电脑上的服务，控制台会报Invalid HTTP_HOST header，这个报错就是ALLOWED_HOSTS导致的。开发阶段直接设成ALLOWED_HOSTS = ['*']省心，部署上线再改成具体域名。

LANGUAGE_CODE和TIME_ZONE如果不改，默认是en-us和UTC。你往后台里录入中文内容，显示时间和排序都会和本地时间差8小时。按时区改成：

LANGUAGE_CODE = 'zh-hans' TIME_ZONE = 'Asia/Shanghai' USE_TZ = True

SECRET_KEY是创建时自动生成的随机串，这个值相当于项目的签名密钥，绝对不能提交到Git仓库。开发阶段不必改它，但要把.gitignore写好，忽略隐藏文件和环境变量的习惯要趁早养成。

DEBUG = True开发阶段保留，后面要部署必须改False。新手容易漏的是：DEBUG=False后Django默认不配静态文件，你的页面会突然全部裸奔，各种CSS样式都没了。这个问题到时候再处理，但你要记住这个因果链条。

2.4 runserver启动后频繁崩溃的排查逻辑

启动服务器后频繁报错，大概率不是runserver本身的问题，而是你的settings.py被改出了问题。比如INSTALLED_APPS里写了个不存在的app名，或者DATABASES的配置拼错了key，启动时都会直接报ImportError或ModuleNotFoundError。

这里教一个基本功：任何修改配置后启动报错，先看完整Traceback的最后一行，那才是错误的真正类型。控制台会输出一大段系统内部的调用路径，别被吓住，往上翻、往最后看，通常就是一行关键信息。

比如报django.core.exceptions.ImproperlyConfigured: Application labels aren't unique，说明两个app用了同一个label。报ModuleNotFoundError: No module named 'xxx'，说明某个第三方库没装，或者INSTALLED_APPS里写错了名称。

配置问题排查时还有个口诀：新加一个配置，就重启一次runserver，不要攒一堆配置一起改然后一次性启动，否则出了问题你都不知道是哪个配置改坏了。

3. App创建与配置：startapp只是入场券，注册才是关键

3.1 创建App后不注册INSTALLED_APPS，模型永远不会被识别

项目创建好后，下一个动作通常是根据功能拆app。命令很简单：

python manage.py startapp blog

然后你的项目目录会多出一个blog文件夹，里面有models.py、views.py、admin.py等文件。但注意，Django不会自动加载这个app。你需要打开settings.py，在INSTALLED_APPS列表里手动添加：

INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'blog', ]

这一步漏掉的话，后果是后面执行数据库迁移时，Django完全不认识你写的模型，makemigrations会提示No changes detected。还有一个隐蔽的坑：漏注册app但访问url时，如果你恰好写出了视图函数，页面能跑通一部分，一旦涉及跨app的model引用，就会报奇怪的AppRegistryNotReady。

具体来说，INSTALLED_APPS里建议写'blog.apps.BlogConfig'而不是单纯写'blog'。BlogConfig是apps.py里生成的配置类，Django会读取它的verbose_name等元信息，在admin后台显示中文名称时就用得到。虽然只写'blog'也能运行，但既然正规做法更利于后续自定义，建议一开始就养成写全路径的习惯。

3.2 urls路由配置，新手最容易栽的两个报错

创建app后，你要把一个页面访问路径绑到某个视图上。Django里路由配置分两步：第一步在项目的urls.py里用include把你的app路由挂进来，第二步在app内部建一个urls.py写具体路径。以blog为例：

# 项目urls.py from django.urls import path, include urlpatterns = [ path('admin/', admin.site.urls), path('blog/', include('blog.urls')), ]

# blog/urls.py from django.urls import path from . import views urlpatterns = [ path('', views.index, name='index'), ]

然后views.py里写：

from django.http import HttpResponse def index(request): return HttpResponse("Hello, Django!")

访问http://127.0.0.1:8000/blog/就能看到输出。这里新手常见的报错是：

django.core.exceptions.ImproperlyConfigured: Specifying a namespace in include() without providing an app_name is not supported。

这是因为你在include里加了namespace参数，但app内部urls.py没有定义app_name。解决办法是在app的urls.py顶部加一行：

app_name = 'blog'

这个app_name在将来做模板反向解析、配合命名空间时都会用到，建议每个app的urls.py都写上。

另一个常见问题是Page not found (404)。如果你创建的路径是path('blog/', ...)，但浏览器访问的是/blog（没有末尾斜杠），Django默认返回404。这是Django的URL规范：路径带不带斜杠，配置里必须一致。开发阶段想要宽松处理，可以设置APPEND_SLASH = True，但说实话这治标不治本，建议还是统一成带斜杠的路径。

3.3 模板目录的创建时机和查找机制

新建的app里默认没有templates文件夹，你需要自己创建。这个位置卡住过很多人：模板文件放哪，怎么写引用路径？

Django的查找规则是：按INSTALLED_APPS的顺序，扫描每个app下的templates目录。也就是说，你可以简单地在blog文件夹下创建一个templates/blog/index.html，然后在视图里直接写return render(request, 'blog/index.html')。

我的建议是：templates下再套一层以app名命名的子目录，也就是templates/blog/。这不算强制要求，但能有效避免多个app里模板同名冲突的问题。

有时候你不想把模板放在app内部，想统一放项目根目录的一个全局templates文件夹，那需要在settings.py里额外配置：

import os TEMPLATES = [ { 'DIRS': [os.path.join(BASE_DIR, 'templates')], 'APP_DIRS': True, } ]

APP_DIRS=True表示依然扫描app内templates目录，DIRS则额外指定了全局搜索路径。新手阶段我建议先只用app内的templates，少一个变量少一个坑。

一旦配错路径或者模板文件位置不对，页面会报TemplateDoesNotExist。这个报错信息其实很明确，它会列出所有搜索过的目录路径，你照着报错往后看就能发现Django去了哪些目录找。如果列表里根本没出现你放模板的目录，那就是路径配置或文件夹拼写问题；如果目录对了但还是找不到文件，那多半是文件名拼错或后缀写错。

3.4 静态文件加载不出来？开发阶段80%是这三个原因

图片、CSS、JS这类静态文件加载不出来的问题，几乎每个Django新手都会遇到。报错页面却是200，但样式全没渲染。开发阶段常见原因就三个。

一是模板界面上没加{% load static %}标签。Django模板默认不知道你要引用静态文件，必须在HTML文件最顶部写上这个标签，然后引用路径时用{% static 'css/style.css' %}。

二是文件放错位置。静态文件默认放在app下的static/app名/目录，比如blog/static/blog/css/style.css。注意Django不会直接扫描app根目录下的任意static文件夹，而是要确实按这个结构存放。

三是STATIC_URL配置被改动或者遗漏。默认settings.py里已有STATIC_URL = 'static/'，这个值是浏览器访问静态文件的URL前缀，保持默认就好，不要随意删。

这里额外说一个生产环境极易踩的事：collectstatic命令。你在开发时静态文件分散在各个app的static目录，部署上线后runserver不再帮你托管静态文件，你需要用python manage.py collectstatic把所有静态文件收集到一个统一目录，由部署服务器统一提供服务。如果没有收集，生产环境的样式就是全部丢失。开发阶段用不到这个命令，但要知道它的存在。

4. 数据库与迁移：创建项目后第一次炸在migrate的概率很高

4.1 默认SQLite零配置，但这一套迁移命令别省

Django创建项目时默认配置的就是SQLite数据库，零配置零安装就能跑。所以你不需要先去装MySQL或者PostgreSQL，直接沿用默认配置就能让模型跑起来。

创建好项目后，第一件事就是把内置的迁移跑一遍，让默认app的数据表建立起来：

python manage.py makemigrations python manage.py migrate

makemigrations是扫描models.py里的变化生成迁移记录文件，migrate是把迁移记录真正执行到数据库。新手容易只执行其中一步。只在makemigrations阶段，你会看到生成了0001_initial.py这样的文件，但数据库里没有任何表；只执行migrate，又会提示没有可迁移的变更。

我建议养成一个习惯：每次改完models.py，都依次执行这两条命令。不要跳过makemigrations直接migrate——migrate执行的是迁移文件而不是直接读取models.py，如果没有迁移文件，改了模型也不会生效。

4.2 makemigrations提示No changes detected？八成是注册或导入问题

写完了模型类，运行makemigrations时得到No changes detected，这个提示很打击人。按照我3.1节说的nginx：app没有在INSTALLED_APPS里注册，Django根本不会扫描这个app下的models.py。

第二个可能原因是模型文件写错了位置。有人图省事把模型类直接写在views.py里，这不符合Django的设计规范。models.py是约定俗成的模型入口，Django会加载这个模块来获取模型定义，写在别处会让迁移工具完全感知不到变化。

还有个隐蔽情况是Meta类里的app_label指定错误，导致模型虽然放在了app A里但Django认为它是app B的，比较微妙不细说。

排查思路很简单：

python manage.py check

这个命令会输出当前的系统完整状态报告，如果模型加载有错误会直接提示。没有报错且依然No changes，再检查INSTALLED_APPS和models.py导入路径。

4.3 迁移过程中经典报错与处理

迁移时报错的典型场景有两个。

第一个是django.db.utils.IntegrityError: (1062, "Duplicate entry ... for key 'PRIMARY'")，一般发生在老数据库表结构和新模型冲突时。比如你数据库里已经有了一条id=1的记录，拖动了一个新模型想让Django建表，但Django尝试插入初始数据失败。处理办法通常是清空对应表或者用python manage.py flush重置数据。

第二个是迁移顺序混乱导致的Migration ... is applied before its dependency ...。这多发生在你手动删除过migrations目录下的文件后，再重新生成。Django的每个迁移文件之间有依赖关系，是用一串随机的迁移名来标识的。如果你删掉了某个中间的迁移文件，依赖链就断了。

一个实用的兜底方法：如果项目还在早期开发阶段，数据都不重要，遇到迁移问题我经常直接删掉所有app下的migrations目录中的迁移文件（保留__init__.py），再重新执行makemigrations和migrate。但注意这个操作只适用于未上线的项目，线上环境数据不能丢。

4.4 时区、编码和中文显示的隐形坑

时区配置在2.3已经提到了，这里展开说一下为什么它会影响查询。

Django开启USE_TZ = True后，所有写入数据库的时间都会统一转成UTC存储，查询时再根据TIME_ZONE转回本地时间显示。这是权威做法，跨时区时不会乱。但如果你数据库里手动插入了中文时间文本，或者Excel导入的数据没有带时区信息，显示出来的时间和预期对不上，多半就是时区转换造成的。

解决办法有两个层面。一是数据入库层面：用django.utils.timezone.now()而不是Python的datetime.datetime.now()，前者会自动带上时区信息。二是查询输出层面：模板里用{{ time_field|date:"Y-m-d H:i" }}过滤标签格式化输出，避免直接裸显示DateTimeField对象。

中文乱码在SQLite环境下通常不会出现，因为SQLite以UTF-8存储。但如果你换成MySQL，必须确认数据库连接配置中有charset=utf8mb4，否则存emoji或者生僻字时会报Incorrect string value。

还有个细节是Django的admin后台默认显示英文。我设置过LANGUAGE_CODE后有时后台仍然是英文，这是因为admin自己的locale文件和请求头语言优先级的问题。刷新浏览器、确认缓存清空后一般就能显示中文。实在不行在settings.py里强制设置：

LANGUAGES = [ ('zh-hans', '中文'), ]

这招基本能定住后台语言。

5. PyCharm导入已有Django项目：功能正常却跑不起来，多半是IDE配置问题

5.1 打开已有项目，方式错了后续全乱

朋友发给你一个Django项目，或者你在GitHub上拉了一个仓库，用PyCharm打开的常规操作是什么？有人直接File→Open选择项目里的settings.py文件，这是完全错误的方式——setting不是项目根。

正确姿势：File→Open，选中包含manage.py的那个文件夹（也就是项目根目录）打开。这样PyCharm才能识别到manage.py，知道这是一个Django项目，才会给你加载Django相关的工具按钮。

打开后PyCharm会弹一个提示，询问是否信任该项目，以及选择Python解释器。如果没弹，手动打开Settings→Project→Python Interpreter，选择你那个虚拟环境里的python解释器。路径在Windows下通常是venv\Scripts\python.exe，macOS/Linux下是venv/bin/python。

选错解释器的直接后果：你在项目里看着settings.py和代码一切正常，但一跑manage.py控制台里报No module named 'django'。就是这个原因——PyCharm实际用的是另一个环境的解释器。

5.2 配置Django Support，不然run按钮都是灰色的

还有一个很多老手也会忽略的步骤：设置Django框架支持。路径为Settings→Languages & Frameworks→Django，勾选Enable Django Support。然后配置两个关键路径：

• Django project root：项目的根目录，也就是manage.py所在层级。
• Settings：指向项目内层配置包里的settings.py文件，路径形如D:\code\mysite\mysite\settings.py。

这两项配置好后，PyCharm的右上角会出现一个绿色的运行按钮，直接点击就能启动runserver，不用每次都在Terminal里敲命令。也能直接打开Terminal里的Django Console，自动加载Django环境，你在里面直接写ORM查询、调试模型都是可以的。

如果你不配置Django Support，运行按钮可能显示的是普通Python脚本运行，或者直接是灰色的，因为你没有配置manage.py的支持。很多新手在这里就卡住了，以为是项目代码问题，其实是IDE没进入Django模式。

5.3 导入后十分钟内跑通的核对清单

导入PyCharm后还不能马上运行，我会按下面顺序检查一遍，缺哪个补哪个：

第一，右上角或设置里确认Python解释器是项目虚拟环境，不是全局解释器。最直观的验证方式：在PyCharm的Terminal面板里执行python -m django --version，能输出版本就是对的。

第二，确认Django Support已勾选并指对了settings.py，运行按钮可用。

第三，确认项目依赖已安装。如果别人给的requirements.txt里带了Django和一堆库，你先在虚拟环境里执行pip install -r requirements.txt，别等到运行时才报缺库。

第四，确认manage.py的路径。这一点看起来废话但很多人忽略：你打开的目录必须包含manage.py，否则PyCharm无法识别项目根。

检查完这四步，直接点运行按钮启动，浏览器访问127.0.0.1:8000出现默认页，导入项目就成功了。

如果按照这个清单检查完了还是报错，大概率是代码本身依赖了某些环境变量，比如settings.py里用os.environ.get('DB_PASSWORD')读取数据库密码但你没设置，此时需要在Run Configuration里给项目配置Environment variables，或者直接在终端启动。

6. 常见报错排查速查与操作顺序建议

6.1 新手高频报错速查表

为了让你在卡住的时候能快速定位，我把创建Django项目阶段最高频的报错整理成一个速查表。这些是我见过至少十遍以上的错误，每个对应一个具体原因和一个解决方向。

这些报错如果你全部经历过一遍，以后再看到就不会慌了。因为它们覆盖面足够广，大部分其他报错都是这些的变种——路径错误、模块未注册、环境不对，就这么三类。

6.2 处理Django报错的核心方法论：从traceback最后一行开始读

我想专门聊一下“怎么读报错”这件事，因为这是新手和熟练工的最大区别。

新手拿到报错喜欢从第一行开始往下读，读到最后一大坨内部路径后彻底晕掉，直接截图到群里求助。而熟练工只看最后一行的异常类型和消息，然后顺着异常追踪栈找自己写的代码文件。

看懂这层逻辑之前，最好先明确：Django的Traceback里80%都是系统内部代码的执行路径，这些系统调用没有错，只是嵌套层数多。真正有问题的，往往在你项目文件的那一行。Traceback底部写着你的文件名为开头的那几行，往上数一段，差不多就是问题代码所在。

定位到问题文件后，推荐一个排查顺序：

1. 看报错类型：比如AttributeError说明某对象没有某个属性，KeyError说明字典取值取了不存在的key，TypeError说明参数类型或数量不对。
2. 看报错消息：有些消息会详细说明... does not exist或者... failed，基本上直接给了答案。
3. 最后再回看代码定位行数，检查变量有没有拼写错误、方法有没有拼错、缩进是否混乱。

记住这三步顺序，定位问题通常会在两分钟之内完成。刻意练习，时间久了肌肉记忆就会养成。

6.3 新手的第一次Django项目，建议按什么顺序操作

最后用我个人带新人的经验，整理一套完整的操作顺序，建议第一次建项目的朋友照着这个顺序执行。

第一轮是环境准备。创建虚拟环境、激活、pip install指定版本的Django，然后原地验证版本。这期间不写任何代码，就是确认环境干净可用。

第二轮是创建项目。python -m django startproject mysite，然后runserver，看到默认火箭页算过关。

第三轮是建第一个app。startapp blog，确认引擎在INSTALLED_APPS里注册。先别急着写模型，先写一个视图返回字符串，把URL路由跑通。先求一个完整的访问流程，再考虑功能扩展。

第四轮是配置数据库。保持默认SQLite，写一个最简模型类，执行makemigrations和migrate，在Django shell里用ORM插入第一条记录并用查询验证读取。

第五轮是接入PyCharm，配置解释器和Django Support，确认IDE里能一键运行。

这五轮全部完成，Django项目的创建期就算毕业了，你后面的所有问题才有基础去解决。不要跳步骤，不要一上来就想做复杂功能，先把这个循环走完，你的Django项目之路会比别人顺很多。

我在实际带人时还有一个感受——创建期最大的敌人不是技术难度，而是同时引入太多变量。只要今天只改设置里的一个配置，也只新增一个app，出了任何问题你都能立刻定位到原因。等你把这些基础路径都走顺了，后面做业务功能时的开发速度会快很多。