简介：OLLAMA Web UI Lite 是一套基于 Web 的轻量级交互界面，用于连接 OLLAMA 后端服务，使开发者无需直接操作命令行，即可通过图形化方式完成模型构建、部署与调试。这份资源主要面向需要在本地快速搭建 OLLAMA 配套前端环境的初中级开发者，内容涵盖完整项目源码、依赖清单、环境配置说明与启动方式，能够帮助用户减少从零配置的摸索成本。资源共 48 个文件，以 svelte 组件、TypeScript 配置、JSON 清单、PNG 预览图、JavaScript 脚本及 Markdown 说明文档为主体，压缩包仅 1.01MB，整体轻量且目录结构清晰。其中，工程配置文件展示了 Svelte、Tailwind CSS、PostCSS 等前端工具在项目中的典型组合方式，常见问题排查文档则汇总了安装与运行环节的注意事项，界面预览图便于提前查看效果，许可证文件明确开源使用边界。已有 767 人学习或下载，适合希望基于现成 Web UI 快速上手 OLLAMA 的开发者，可作为本地部署前端交互界面及后续二次开发的完整参考。

1. Ollama安装：本地大模型部署的入口，卡在版本选择上的人远比想象中多

Ollama 这个工具，最近两年几乎成了本地跑大模型的默认起点。一条命令拉模型、一条命令起服务，看起来没什么门槛，但真正开始装了才发现，坑全藏在版本选择和环境参数里。我在某公司给内部做的那个模拟项目X，就因为在 Windows 和 Linux 两套环境里分别踩了不同版本的坑，前前后后折腾了两天才把 Ollama + 一个轻量 Web UI（ollama-webui-lite）完整跑通。装不好会怎样？最典型的就是模型拉取到一半直接断掉、API 通了但界面加载不出来、或者显卡明明很贵但推理速度慢得离谱。这篇文章写给两种人：一种是刚接触 Ollama、想在自己电脑上装一套能用的环境；另一种是已经装了但用得别扭、想搞清楚版本和参数之间关系的开发者。我会把 Ollama 本体安装、模型拉取、WebUI 对接以及常见异常处理全部过一遍，每个步骤都给出我实际用过的命令和配置。

2. 安装前的环境准备：Ollama的硬件选型和版本选择

2.1 硬件门槛：CPU、内存、显卡怎么配

先别急着装，搞清楚你的机器能跑什么级别的模型再动手。Ollama 本身的安装包很小，一百多兆，但它真正吃资源的是模型文件。以目前常用的 qwen2.5 系列为例，7B 参数的量化版本大约需要 6~8GB 的内存或显存，13B 就要翻倍。这是非常粗略的估算，模型量化精度、上下文长度设置都会影响实际占用，但先按这个量级判断不会离谱。

内存方面，如果是纯 CPU 推理，32GB 内存起步会比较从容，16GB 只能跑 3B 左右的小模型，而且速度会慢得让人怀疑电脑坏了。显卡方面，NVIDIA 卡首选，因为 Ollama 对 CUDA 的支持最成熟，AMD 卡和 Intel 卡也能用，但驱动和参数调起来会费更多时间。显卡容量决定你能跑多大的模型，速度决定你等不等得起，两者都很影响使用体验。

磁盘空间这块容易被忽略。默认模型存储目录在 Linux 下是~/.ollama/models，Windows 下是C:\Users\用户名\.ollama\models，一个模型动辄 4GB 往上，多换几个模型试，几十GB 一下子就没了。我一般会提前确认这个目录所在分区剩余空间在 40GB 以上，否则拉第三个模型的时候就该翻车了。

硬件确认完之后，还要检查系统环境。Ollama 官方支持 macOS、Linux、Windows，三者的安装方式完全不同。macOS 和 Windows 有安装包，Linux 用一键脚本或者手动解压二进制文件。如果你用的是 Linux 服务器，建议重点关注显卡驱动的版本，这往往是推理环境能否跑起来的关键变量。

2.2 Ollama版本怎么选：安装包、脚本、包管理器三条路

Ollama 的版本选择是我在实战中花费最多时间的地方。虽然官方更新频率很高，但并不是每个版本都值得追新。先看三张表的对比，然后根据自己的系统类型选安装路径。

我自己在 Linux 服务器上一般会用官方的一键脚本，因为要部署到多台机器上，脚本方式最容易自动化。但有个很重要的点：一键脚本默认安装的是当前最新正式版，如果想锁定版本，需要修改脚本中的版本号。这里贴一个实际用的脚本：

curl -fsSL https://ollama.com/install.sh | sh

这段命令从官网拉取安装脚本并执行，日常部署足够用了。如果你在墙外网络环境正常，这条命令基本不会有问题；如果下载速度极慢，可能需要确认网络出口是否稳定。要注意的是，sh直接执行外部脚本是有安全风险的，所以我通常会先下载脚本看一眼内容再执行：

curl -fsSL https://ollama.com/install.sh -o install.sh head -50 install.sh sudo sh install.sh

这样至少知道脚本里做了什么，不至于让一个陌生脚本直接在 root 权限下跑完。

Windows 端就简单多了，直接下载官方安装包，双击一路下一步。但这里有第一个坑：Windows 安装包默认把模型放在 C 盘，如果你的 C 盘空间紧张，装完模型库之后很快就会爆盘。不建议在安装时改路径，而是装好了之后设置OLLAMA_MODELS环境变量来改变模型存储位置，这个后面会细说。

macOS 端则两种情况都有，Apple Silicon 芯片和 Intel 芯片的安装包版本有差异。现在官方已经统一了安装包，但 Apple Silicon 上跑 Ollama 的量化加速效果明显优于 Intel 芯片，这一点在选机器时就该考虑进去。

版本锁定的具体做法是：在 Linux 里，脚本支持用环境变量指定版本号，含义与官方文档一致。常见做法是直接在下载 URL 里写死版本，例如指定 0.5.7 这样的版本号。如果你的应用和某个模型已经调通，不建议频繁升级 Ollama，因为服务起停的接口参数偶尔会有变动，很可能升级完之前能跑的脚本就莫名报错了。

2.3 下载前先确认：系统依赖和网络出口

安装前还有几个前置项要确认。Linux 系统需要确保有curl和tar命令，这两者通常系统自带，但精简版系统可能没装。用以下命令安装缺失的依赖：

sudo apt update sudo apt install curl tar -y

那为什么tar也很关键？因为 Ollama 的 Linux 包是以tar压缩包形式下载再解压到/usr/local的。一键脚本本质上做的就是下载、解压、配置 systemd 服务这三件事，缺了系统工具脚本就会中断。

网络方面要确认两个出口：下载 Ollama 安装包时要能正常访问官方下载源；拉取模型时要能访问模型仓库。这两个域名走的不是同一个 CDN，所以有可能安装包下载很快，但模型死活拉不下来。遇到这种情况，先别怀疑命令写错了，大概率是模型仓库的连通性有问题。解决方案要么配置代理出口，要么换个时间段再试，要么用现有的国内镜像服务。这属于常见做法里最稳妥的一条路，不涉及对 Ollama 本身的改动。

3. 安装Ollama与拉取模型：从零到本地跑通

3.1 三步装好Ollama本体

把 Ollama 装到 Linux 服务器上，我习惯分成三步走，方便在出问题时定位环节。第一步下载并解压，第二步配置系统服务，第三步设置环境变量。

先下载最新版的二进制压缩包。这里我把版本号写成变量，方便以后升级时只改一行：

export OLLAMA_VERSION="0.5.7" sudo mkdir -p /usr/local/lib/ollama sudo curl -L "https://ollama.com/download/ollama-linux-amd64.tgz" -o /tmp/ollama.tgz sudo tar -C /usr/local/lib/ollama -xzf /tmp/ollama.tgz

这段脚本先把压缩包下载到/tmp，然后解压到/usr/local/lib/ollama。这里要说一下为什么解压到这个目录而不是直接拖到/usr/bin，因为 Ollama 的可执行文件和相关库文件比较多，摆在一起方便查看版本和管理依赖。解压后主程序地址是/usr/local/lib/ollama/bin/ollama。

第二步是建符号链接，让ollama命令直接可用：

sudo ln -sf /usr/local/lib/ollama/bin/ollama /usr/local/bin/ollama ollama --version

符号链接的作用是把真实安装路径映射到系统命令搜索路径下。-f参数表示如果已有同名链接就覆盖。这个技巧能帮你绕过 PATH 环境变量配置问题，同时也方便查看安装版本确认是否成功。

第三步是启动服务。Linux 下一键脚本会自动注册 systemd 服务，但如果手动解压，需要自己创建服务文件。以下是我常用的ollama.service内容：

[Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/usr/local/lib/ollama/bin/ollama serve User=root Group=root Restart=always RestartSec=3 Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" [Install] WantedBy=default.target

把这段内容保存到/etc/systemd/system/ollama.service，然后执行：

sudo systemctl daemon-reload sudo systemctl enable ollama sudo systemctl start ollama sudo systemctl status ollama

这里有个细节要注意：ExecStart里写的是ollama serve，这个命令是启动 Ollama 后台服务的核心指令。如果你在终端直接执行ollama serve，也能启动服务，但一旦关闭终端，服务就停了，所以生产环境务必走 systemd 托管。Restart=always意味着服务异常退出后会自动拉起，省去了手工干预的麻烦。

3.2 模型拉取：用对model name比改参数更省心

模型拉取是 Ollama 安装中必不可少的一环。没有模型的服务就像一个空壳，拉取模型用命令是：

ollama pull qwen2.5

这个命令会从官方模型库拉取 qwen2.5 的最新默认版本。ollama pull背后做的事情包括：下载模型分片文件、校验完整性、解压到本地模型目录、生成运行时索引。看起来简单，但有几个参数值得细看。

首先，模型名可以带标签，比如qwen2.5:7b-instruct-q4_K_M这样的格式。标签决定了具体的量化格式与参数规模。如果只写qwen2.5，拉下来的是默认标签，可能不是你想要的那个版本。我通常在拉取前先到模型库页面确认有哪些可用标签，避免拉下来一个 14B 的大模型，把内存直接占光。

其次，拉取中断后可以继续。Ollama 的下载支持断点续传，再次执行同样的ollama pull命令，会从上次中断的地方继续，不需要删掉重拉。这一点在模型文件特别大、网络又不稳定的时候，显得格外实用。

如果你在元数据量比较大的模型列表里找名字，还有一个实用的命令：

ollama list

这条命令列出本机已经拉取的所有模型，包含模型名、标签、大小。到这里，模型已经落盘，可以用它来测试本地对话：

ollama run qwen2.5 "你好，介绍一下你自己"

首次运行会有一个加载过程，时间取决于模型大小和磁盘速度。加载完成之后，终端会进入一个交互式对话界面，可以在里面连续聊天。ollama run如果不想进入交互模式，直接跟提示词参数，它就是单次回答然后退出，这是脚本调用时更常用的方式。

3.3 用Ollama自带API验证服务已经起来

装好服务、拉好模型之后，最要紧的事情是验证服务确实对外可用。Ollama 自带的 REST API 是验证的最佳工具。默认服务监听11434端口，通过以下命令可以查看：

curl http://localhost:11434/api/tags

正常情况下，会返回一个 JSON 结构，里面有已安装模型的列表。如果返回空或连接拒绝，先确认服务进程是否存在：

ps aux | grep ollama

再查看端口占用：

ss -tlnp | grep 11434

这两个命令配合能快速判断问题是出在服务没启动，还是端口被别的东西占了。端口被占的情况偶尔会遇到，比如某些软件默认端口恰好也在 11434 附近。如果端口被占，修改 Ollama 的监听端口通过环境变量OLLAMA_HOST实现，比如设置成0.0.0.0:11435，改完重启服务：

export OLLAMA_HOST="0.0.0.0:11435" sudo systemctl restart ollama

注意，环境变量需要写入 systemd 服务文件或者系统环境配置里才会持久生效，直接在终端 export 只对当前会话有效。我一般会写进/etc/systemd/system/ollama.service的[Service]段下，加一行Environment="OLLAMA_HOST=0.0.0.0:11435"，然后daemon-reload重启。

API 验证还有一个更深入的测试：直接发起一个对话请求，确认模型推理链路完整。命令如下：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5", "prompt": "你好", "stream": false }'

stream参数设为false表示一次性返回完整结果，方便在终端里查看。如果返回内容中包含"response"字段且非空，说明 Ollama 服务、模型加载、推理引擎全链路正常。如果超时，就要考虑模型正在加载、硬件性能不足或显存不足。

4. 部署ollama-webui-lite：给命令行服务套一层图形界面

4.1 ollama-webui-lite环境要求

Ollama 本身是命令行工具，但对于日常使用，尤其是给团队内部非技术同学用，一个 Web UI 能极大降低使用门槛。ollama-webui-lite 是众多 Ollama Web 界面中比较轻量的一款，它不需要单独的后端服务，直接以静态页面方式运行，通过浏览器访问，依赖起得很简单。

在部署之前先理清需求：ollama-webui-lite 做的事情是调用 Ollama 的 REST API，把对话界面呈现给用户。因此它本身不承载模型推理任务，只是转发请求和渲染响应。这也意味着，它需要能访问到 Ollama 服务的地址，如果 Ollama 只监听了localhost，而 WebUI 跑在另一台机器上，就调不通。

ollama-webui-lite 对运行环境的要求不高，Node.js 环境或纯静态服务器都可以。Node.js 版本建议 18 以上，几行命令就能验证当前环境：

node --version npm --version

如果版本过旧，建议先升级 Node.js，因为某些依赖包已经不支持旧版本的运行环境了。这个点经常被忽略，我见过一个报错就是 Node 14 环境上跑 npm install 直接失败，错误提示完全看不懂，最后看依赖包的 engines 字段才发现是 Node 版本问题。

4.2 安装步骤：npm、源码、Docker三选一

ollama-webui-lite 的部署方式我试过三种，这里把主流的路径和要点都列出来。

第一种是 npm 直接启动，这是最快的方式：

git clone https://github.com/ollama-webui/ollama-webui-lite.git cd ollama-webui-lite npm install npm run dev

三个命令分别做了什么事情？第一条是把前端源码克隆到本地；第二条安装该项目的依赖包，这在 npm 生态里是标准步骤；第三条是在开发模式启动一个本地服务，默认端口通常是 3000。启动成功后，浏览器访问http://localhost:3000，就可以看到对话界面。

第二种是构建静态文件后用 Nginx 托管，这个适合正式一点的部署场景：

npm run build

构建完成之后，dist目录下就是可部署的静态文件。把这个目录拷贝到 Nginx 的html目录下，Nginx 配置里指向这个路径即可。此方式的好处是不需要常驻 Node 进程，一个 Nginx 就搞定了，而且静态文件部署在局域网内其他机器也能直接访问。

第三种是用 Docker 部署，如果你本来就在用容器，这条路最省事：

docker run -d --name ollama-webui-lite -p 3000:3000 \ -e OLLAMA_API_BASE_URL=http://host.docker.internal:11434 \ ghcr.io/ollama-webui/ollama-webui-lite:main

容器的启动参数里有一个环境变量叫OLLAMA_API_BASE_URL，作用是告诉 WebUI 去哪里找 Ollama 服务地址。注意host.docker.internal是 Docker 里访问宿主机地址的特殊域名，Windows 和 Mac 上可用，Linux 上需要额外配置extra_hosts参数。这个细节如果没留意，容器起来以后页面会一直报连接失败，你还会误以为是 WebUI 本身出了问题。

4.3 配置OLLAMA_HOST与跨域，打通WebUI到推理引擎的路

部署完 WebUI 只是第一步，真正容易卡住的是 WebUI 与 Ollama 服务之间的联通问题。网页端通过浏览器向 Ollama 的 API 发请求，浏览器安全策略就对跨域请求有严格限制，如果 Ollama 没有允许跨域，WebUI 的请求会被浏览器拦截。

配置方式分两层。第一层，Ollama 监听地址要改成对外可达的地址。默认 Ollama 绑定的是127.0.0.1，只有本机能访问。WebUI 如果跑在同一台机器上，这个没问题；如果 WebUI 在别的机器或容器里，就必须让 Ollama 监听外部地址：

sudo systemctl edit ollama

这个命令会打开一个覆盖配置文件，写入：

[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"

然后重启服务：

sudo systemctl daemon-reload sudo systemctl restart ollama

OLLAMA_HOST设置为0.0.0.0表示监听所有网络接口。如果只是想让局域网内的特定机器访问，更安全的方式是直接写那台机器的 IP，比如192.168.1.100:11434，所以按需选择即可。这里涉及安全取舍，需要提醒的是：0.0.0.0会让任何能到达这台机器端口的人直接调用模型，在没有鉴权机制的情况下，建议只在可信内网使用。

第二层，确认 WebUI 配置的 API 地址是否正确。ollama-webui-lite 一般在项目根目录的.env文件中配置，启动前看一下：

cat .env

常见配置项如下：

OLLAMA_API_BASE_URL=http://localhost:11434

如果 Ollama 不在本机，将这个地址改成 Ollama 所在机器的 IP。改完重新启动 WebUI 即可，这个配置是前端打包时直接注入的，所以修改后要重新构建或重启 dev server，刷新页面是无效的，容易误判。

5. 常见问题排查：这六个坑我全部踩过一遍

5.1 模型下载到99%就卡住

现象是执行ollama pull时，下载进度到 99% 就长时间不动，等半小时也没有任何进展，最后进度条停了，ctrl+C 退出，重试还是同样的情况。这个现象我遇到时第一反应还以为是磁盘满了，查了df -h却发现剩余空间充足。

原因是下载的最后阶段需要对已下载的分片文件做校验和解压，而这个环节耗CPU时间且在文件较大时尤其明显；如果同时系统内存压力很大，解压进程被拖慢甚至卡死，就会看起来像卡在 99% 不动。常见的处理流程是先查看系统负载：

top -o %CPU

如果 Ollama 相关进程 CPU 占用很高，证明它在校验或解压，再等一会儿就好。如果 CPU 占用几乎为零，说明网络连接已经断开，需要中断后重新执行ollama pull，它的下载策略支持断点续传，重新执行不会从头拉取。

还有一个容易被忽视的点：磁盘分区满了也可能导致解压失败，但这个失败通常会报错而不是卡住。所以处理这个情况时，我会先查磁盘再查 CPU 负载，两条命令一起跑就能快速定位问题。

5.2 API能通，但WebUI一直转圈

现象是curl调用 Ollama API 正常返回，但浏览器打开 WebUI 后，发送消息后页面一直转圈，什么也不返回。这个问题排查起来线索很杂，我前前后后花了不少时间才发现根源。

原因是浏览器端发出的请求和curl发出的请求有一个本质区别：浏览器带上了Origin头，触发 CORS 跨域检查。Ollama 默认的 CORS 配置只允许部分来源，WebUI 的地址不在允许列表里，于是请求被拦截，页面拿不到响应。

解决方法是给 Ollama 的服务配置增加允许的来源。一种做法是配置环境变量来放开跨域限制，另一种是在反向代理层面加 CORS 头。我比较推荐前者的一个简单版本（该变量名称视版本略有差异）：

export OLLAMA_ORIGINS="*"

把这个变量写入 systemd 服务文件后重启服务。OLLAMA_ORIGINS="*"允许所有来源跨域访问，方便是真方便，但对于生产环境而言存在放松策略的隐患，建议改成具体的域名比较妥当。从那以后我每次部署 Ollama 对外服务，都会第一时间检查两个环境变量：OLLAMA_HOST和OLLAMA_ORIGINS。

5.3 4090显卡跑不满，速度还不如CPU

现象是显卡明明配置不低，跑一个 7B 模型的速度却慢得离谱，speed显示只有几 token/s，甚至不如纯 CPU 推理。

原因主要有两个。一是 Ollama 没有检测到 GPU，回退到了 CPU 推理模式。检查方法用：

ollama ps

这个命令会显示当前加载的模型及其运行设备，如果设备显示的是 CPU，说明 GPU 检测失败或驱动问题。再看看日志输出，如果是 Linux 环境，出现no CUDA-compatible device found之类的日志，说明 Ollama 的 GPU 相关库没有正确加载。

解决路径是先确认 NVIDIA 驱动装好了：

nvidia-smi

这个命令正常输出显卡型号和驱动版本，表示驱动层面没问题。然后确认 CUDA 相关库存在。Ollama 的 Linux 安装包会内置运行时所需的 CUDA 库，不需要另外安装完整的 CUDA Toolkit，但如果之前手动安装过其他版本可能有冲突。此时可以尝试重新安装 Ollama 本体，强制重新解压所有库文件。

另一个情况是当前同时跑了好几个模型，显存被瓜分，每个模型分到的显存不足以支持全面加速，Ollama 只能部分加载到 GPU。可以用ollama ps看到显存占用，或者直接重启服务并只加载一个模型，速度恢复即确认是这个原因。

5.4 11434端口被占用，Ollama起不来

现象是启动 Ollama 服务时，systemd 报了进程启动失败，查看日志发现端口被绑定失败。这种场景我在多台服务器上遇到过，而且占端口的进程五花八门，有时候是监控代理，有时候是某些绿软偷偷监听了所有端口。

排查的命令很明确：

sudo lsof -i :11434

或者：

sudo netstat -tlnp | grep 11434

lsof在部分精简系统里没有装，用netstat也一样。看到占用进程之后，要么停掉那个进程，要么把 Ollama 换一个端口。重要提醒：如果服务器上有其他服务也依赖 11434 端口，改 Ollama 端口前，WebUI 端的配置也要同步改，否则前面已经调通的界面会立刻不可用。

5.5 换模型后WebUI界面不刷新

现象是拉了一个新模型，WebUI 的模型列表里看不到，刷新浏览器也不行。

原因是 WebUI 的模型列表是从 Ollama API 获取的，而有的缓存策略会保留旧列表。解决方法是强行刷新页面，或者直接清掉浏览器对该站点的缓存；如果还不行，重启一下 WebUI 服务进程让它重新加载配置。这套做法不影响 Ollama 本身的模型数据，本质上只是前端数据同步的问题。

5.6 中文对话乱码

现象是 Ollama 在终端里回答中文内容正常，但 WebUI 显示出来却是乱码。

多数情况是浏览器的页面编码不对，或者 WebUI 构建时没有默认字符集。先看页面 meta 标签，标准做法是确保 HTML 里有<meta charset="UTF-8">，如果是静态构建的版本，重新构建一次基本能解决。另外确认模型本身是否支持多语言，某些模型的中文能力取决于训练内容，如果模型本身中文回答质量差，也会被误认为乱码。

以上六个坑覆盖了安装、对接、推理、显示四大环节，是我在多个项目环境里积攒下来最常见的问题。排查的时候千万别急着重装，先确认服务状态、端口、环境变量这三件事，大多数问题都能定位到具体原因。

6. 装完怎么验证跑通：从API到WebUI全链路自检

环境装完之后，最怕的就是看似一切正常，实际一步都走不通。我习惯性地把验证拆成三个层次，逐层推进，这样可以精确锁定问题环节。

第一层，验证 Ollama 服务和模型加载是否正常：

ollama list curl http://localhost:11434/api/version

第一条命令能看到模型列表，说明服务端能识别模型。第二条调用版本接口，如果返回{"version":"0.5.7"}这样的 JSON，说明 API 网关正常响应。这两条是基础，不通过则先修这里。

第二层，验证实际推理链路：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5", "prompt": "用一句话介绍你自己", "stream": false }'

这里要注意"stream": false的作用。设为false时服务端会等生成完毕再一次性返回，适合快速验证模型可用性；设为true则流式返回，适合测对话流畅度。如果返回内容里的"response"字段不为空，说明模型推理、显存分配、上下文管理都正常。

第三层，验证 WebUI 实际可用。打开浏览器，访问 WebUI 的页面，先确认页面加载正常，再选择一个模型，发送一条简单消息。观察底部 token 计数，确认请求和响应都经过了完整的前后端链路。如果 UI 能收到完整回复，且速度体感正常，说明 Ollama 服务和 WebUI 的对接已经完全跑通。

除了功能验证，我还会检查一个容易被忽略的性能项：并发负载。用ollama ps可以看到模型占用的显存大小，结合nvidia-smi看实际显存使用率，判断模型是全量加载进显存还是部分落在内存里。

做完整套验证之后，我会顺手记录当前使用的 Ollama 版本、模型标签、WebUI 提交时锁定的版本信息，这些信息在以后排障时会很有用。从那以后，我每次新装环境都会强制走一遍这三个层次的验证流程，确认响应非空、UI 有输出、显存数值正常，才认为是真正跑通了。希望帮到你。

本文还有配套的精品资源，点击获取