从标题看这像是一个开发者终于把手里的免费AI聊天引擎搬上手机端的里程碑时刻。但真正让我感兴趣的不是“王炸功能”这四个字而是这类项目背后一套完整的移动端聊天架构免费的模型服务、跨端的前端框架、流式输出的处理、再加上一堆手机端特有的兼容问题。如果你也想自己搭一个能在手机上随手打开的AI聊天应用这篇就来拆解它到底由哪些部分组成以及怎么从零跑通一条最小链路。先说结论手机端AI聊天项目的技术门槛并不在模型本身而在于三层问题。第一层是模型服务怎么选免费方案通常有“本地部署开源模型”和“云端免费额度”两条路第二层是手机端怎么和模型服务通信聊天场景要求每生成一个字就刷新一次这就离不开流式协议第三层是做进手机壳之后的状态栏、跨域、版本一致性等工程细节。搞懂这三层你也能复刻一个免费AI聊天引擎的手机端。这篇文章不会去比较哪个模型“更聪明”而是先给出一套可落地的参考架构用Ollama跑开源模型用FastAPI写一个SSE流式聊天接口再用uni-app做一个跨iOS和Android的聊天页面。代码会分成后端、前端、运行验证三部分最后还会把手机端开发里最容易踩的坑列出来。1. 为什么手机端AI聊天值得自己搭现在市场上并不缺AI聊天App但我身边很多开发者最终都走向了自建。原因集中在三方面订阅成本高、数据不在自己手里、功能不能按需改。官方App往往采用会员订阅制每月费用不低而且聊天记录和个性化配置大多绑定云端一旦你想要一个自己的提示词模板、一个本地知识库入口或者只是想改一下界面字号官方产品基本不会给你开口。“免费AI聊天引擎”真正吸引人的地方不是白嫖一个模型而是把“对话能力”变成自己项目里的一个模块。比如给现有业务加一个智能客服、给个人工具加一个语音助手这些场景都需要一个能自由定制、能嵌入到手机端应用里的引擎。自己做出来的东西模型可以随时换接口可以随手改数据也可以只留在本地服务器。从成本角度看免费通常分两种。一种是本地部署开源模型只要电脑或服务器跑得动就没有接口费用也没有调用次数限制但需要电费和硬件投入另一种是使用云厂商的免费额度接入简单、响应快但通常有频率上限而且要注意密钥不能暴露在客户端。这篇示例以Ollama本地模型为主因为链路最简单不依赖外部服务也不需要申请各种密钥特别适合先跑通流程。适合读这篇文章的读者大致有三类。第一类是已经用过ChatGPT或各类AI工具想自己做一个简易聊天App的前端开发者第二类是公司内部要做AI客服或AI助手需要一个轻量MVP做验证的后端开发者第三类是刚接触移动端开发想同时了解SSE、跨端框架、本地模型服务这些概念的学生或爱好者。如果你只是想要一个能用的聊天软件直接装现成App更省事但如果你想要一个能改、能扩展、能私有部署的聊天引擎这篇文章可以帮你把第一版跑起来。2. 手机端AI聊天项目整体架构与选型2.1 三层架构手机端、网关服务、模型服务手机端AI聊天项目虽然看起来是一个“App”但按职责拆分后至少有三层。最上层是手机端负责展示消息、收集输入、维护聊天界面中间层是后端网关服务负责接收手机端的请求、调用模型、把结果流式返回最底层是模型服务可以是一台运行Ollama的本地机器也可以是一个远程API服务。为什么中间一定要加一层后端网关而不是让手机端直接连模型这里有两个很现实的原因。第一是密钥安全模型服务的API Key如果写在手机App里客户端一旦被破解密钥就泄露了在后端统一调用模型手机端只面对自己的业务接口。第二是协议统一手机端只需要知道如何请求自己的后端至于后端调的是Ollama还是云API手机端完全不用关心后续换模型服务不用重新发版。2.2 技术选型对比与理由前端框架方面目前主流可选uni-app、Flutter、React Native。这里我建议用uni-app理由很实际它基于Vue语法前端开发上手快一套代码可以编译到iOS、Android和H5微信小程序也能覆盖。对于“手机端AI聊天”这种以表单、列表、滚动文本为主的界面uni-app的成熟组件完全可以胜任而且国内社区资料多遇到问题容易搜到。后端方面选择Python FastAPI看重的是它对异步流式支持非常好。聊天接口需要把模型逐步生成的内容持续推给前端FastAPI的StreamingResponse配合异步生成器写起来很直观。Node.js也能做但FastAPI在数据建模和接口文档上更省事启动项目后自带Swagger文档方便调试。模型服务选择Ollama重点在于它把本地运行开源模型的复杂度降得非常低。一条命令拉模型一条命令启动服务还提供了OpenAI兼容接口意味着上层代码可以按统一规范编写。换成其他模型平台时只要接口兼容改动量很小。2.3 两条实现路线的取舍如果只想做最小Demo可以跳过后端手机端直接请求云端兼容接口但你需要自己处理跨域、密钥暴露和流量计费问题。这种方式适合个人临时测试不适合作为工程化项目的基础。更稳的做法是本文采用的“手机端 后端网关 本地模型”模式开发阶段链路稍长但每一步都可控。如果团队里有服务器本地部署模型的体验更像“私有化AI引擎”。在算力允许的情况下可以同时挂多个模型按业务场景切换。如果服务器配置一般则可以考虑云端免费额度但要在后端做一层缓存和限流避免免费额度被刷爆。不管选哪条路线手机端代码都建议保持“只对接业务接口”的姿势为以后替换模型服务留出余地。3. 基础概念说明SSE、OpenAI兼容接口与Token3.1 什么是SSE流式输出SSE全称Server-Sent Events从名字可以看出来这是服务器主动向客户端推送事件的协议。在AI聊天场景里模型不是一次性把整段话生成完而是逐个Token生成如果不做流式用户发出问题后可能要等十几秒才能看到结果体验非常差。使用SSE后后端每生成一小段内容就立刻通过HTTP连接推给前端屏幕上就会呈现“逐字输出”的效果。SSE和WebSocket的区别很多新手会搞混。WebSocket是双向通信适合聊天室、实时协作这类前后端频繁互动的场景SSE是单向的由服务器向客户端持续推送但它建立在普通HTTP之上实现简单、自动重连也方便。AI对话本质上是用户发一次请求服务器持续回一段话正好落在SSE的优势区间。3.2 OpenAI兼容接口为什么重要OpenAI兼容接口指的是/v1/chat/completions这一类标准接口格式请求和返回结构都有固定规范。只要模型服务实现了这个协议上层业务代码就可以用同一套逻辑对接不同模型。Ollama目前也提供了这样的兼容接口这让本地模型和云端模型在代码层面保持了一致。兼容接口的流式返回每一行以data:开头最后以data: [DONE]结束。前端解析SSE流时只需要不断按行读取凡是以data:开头的内容都按JSON解析取其中的增量文本字段看到[DONE]就停止。这个数据格式是整个聊天链路的关键后续示例代码就是围绕它展开的。3.3 Token与上下文窗口Token可以简单理解为模型处理文本的最小单位中文场景下一个字可能对应一到两个Token不同模型的切分方式不一样。模型一次能接收的最大Token数叫上下文窗口超出后要么报错要么需要做截断。在聊天功能里对话历史会越来越长如果不做控制很快会撑满上下文。常见的做法是只保留最近几轮消息比如保存最近10轮对话旧消息在发往模型之前过滤掉。这样既能节省Token消耗也能减少模型响应延迟。更好的方案是把早期对话摘要成一段总结与最近消息一起发送但这属于后续优化的方向。对于第一版滑动窗口截断已经够用。4. 环境准备与前置条件4.1 模型服务环境安装Ollama本示例以Ollama作为模型服务安装过程比较直接。Ollama支持Windows、macOS和Linux官方安装包下载后即可运行。安装完成后在终端启动服务并拉取一个适合聊天对话的中文模型。下面给出常用命令# 启动Ollama服务 ollama serve # 单独打开一个终端拉取qwen2.5系列模型 ollama pull qwen2.5:7b执行ollama pull命令时会从模型仓库下载模型文件文件大小取决于模型规格。以7B规模模型为例通常需要几个GB磁盘空间下载耗时取决于网络。下载完成后可以先用命令行快速验证模型能否正常对话ollama run qwen2.5:7b 介绍一下你自己如果模型能在终端里输出回答说明Ollama服务正常可以继续搭建后端。需要注意qwen2.5:7b只是一个示例标签实际可用的模型名称以Ollama官方模型库为准。4.2 后端运行环境后端代码使用Python编写建议使用Python 3.10及以上版本因为后面的示例代码用到了较新的类型注解写法。项目依赖使用pip管理主要安装FastAPI、Uvicorn和HTTP客户端库。Uvicorn用来启动Web服务httpx用来让后端异步调用Ollama接口。安装依赖的命令如下pip install fastapi uvicorn[standard] httpx安装完成后可以执行python --version确认Python版本再执行uvicorn --version确认服务工具可用。如果电脑上有多个Python环境建议先创建虚拟环境避免依赖冲突。这个后端项目本身不连数据库第一版可以把聊天历史交给手机端本地存储。4.3 前端运行环境手机端项目选择uni-app开发环节有两种方式。一种是使用HBuilderX可视化创建项目优点是界面操作简单适合不需要命令行构建的开发者另一种是使用命令行创建Vue3 Vite模板适合习惯使用VS Code等编辑器的开发者。这里以命令行模板为例npx degit dcloudio/uni-preset-vue#vite my-ai-chat cd my-ai-chat npm install npm run dev:h5如果本机还没有安装Node.js需要先从Node.js官网下载LTS版本安装。npm install可能会花一点时间因为要下载依赖包。npm run dev:h5的作用是在浏览器里启动H5版页面方便开发调试后续需要打包成App时再用HBuilderX或官方命令行工具发布。5. 构建聊天后端服务5.1 后端项目结构一个小型后端不需要复杂的目录先让代码可运行比什么都重要。建议在后端目录下至少包含两个文件requirements.txt用来记录依赖main.py用来放FastAPI应用和接口逻辑。后续如果项目变大再按模板、路由、服务层拆分。项目结构如下chat-backend/ ├── requirements.txt └── main.py这里的核心思路是只暴露两个能力接收手机端发来的对话消息把模型返回的增量内容以SSE流式推给手机端。main.py里会包含CORS配置、请求体定义、Ollama调用逻辑和流式返回逻辑。5.2 写入依赖文件创建requirements.txt把运行时依赖写进去。这里不锁定具体版本安装时取其当前可用版本即可。如果你需要锁定版本保证上线可重复建议安装成功后用pip freeze重新生成依赖列表。fastapi uvicorn[standard] httpx保存在后端目录后执行pip install -r requirements.txt完成依赖安装。如果在真实生产环境中还会加入日志、配置中心、链路追踪等组件但当前MVP阶段不需要。5.3 实现SSE聊天接口下面这段代码实现了一个完整的/api/chat接口。它接收到手机端传来的消息列表后调用本机Ollama的/v1/chat/completions兼容接口并把模型返回的增量内容逐个包装成SSE数据行返回给前端。# -*- coding: utf-8 -*- # 文件路径main.py from fastapi import FastAPI from fastapi.middleware.cors import CORSMiddleware from fastapi.responses import StreamingResponse from pydantic import BaseModel import json import httpx app FastAPI() # 开发阶段放开跨域生产环境建议改成具体域名 app.add_middleware( CORSMiddleware, allow_origins[*], allow_credentialsFalse, allow_methods[*], allow_headers[*], ) # 本地Ollama默认地址 OLLAMA_BASE_URL http://127.0.0.1:11434 MODEL_NAME qwen2.5:7b class ChatMessage(BaseModel): role: str content: str class ChatRequest(BaseModel): messages: list[ChatMessage] temperature: float 0.7 def parse_sse_line(line: str): if not line.startswith(data:): return None data line[len(data:):].strip() if data [DONE]: return None return json.loads(data) async def generate_stream(messages: list[ChatMessage], temperature: float): payload { model: MODEL_NAME, messages: [m.model_dump() for m in messages], stream: True, temperature: temperature, } async with httpx.AsyncClient(timeout60) as client: async with client.stream( POST, f{OLLAMA_BASE_URL}/v1/chat/completions, jsonpayload, ) as resp: async for line in resp.aiter_lines(): parsed parse_sse_line(line) if not parsed: continue choices parsed.get(choices) or [] if not choices: continue delta choices[0].get(delta) or {} content delta.get(content) if content: yield fdata: {json.dumps({content: content}, ensure_asciiFalse)}\n\n app.post(/api/chat) async def chat(req: ChatRequest): return StreamingResponse( generate_stream(req.messages, req.temperature), media_typetext/event-stream, )这段代码的核心在generate_stream函数。它用httpx.AsyncClient请求Ollama的流式接口按行读取响应每读到一条包含增量内容的JSON就把它转换成统一格式的SSE消息。这样不管底层模型返回的结构有多少差异手机端拿到的始终是{content: ...}这种统一格式。需要特别提醒的是这里为了演示方便跨域配置写成了allow_origins[*]。这只能用于本机开发和局域网联调如果部署到公网必须改成受信任的来源列表并考虑增加请求鉴权否则任何网页都能向你的接口发起请求。5.4 接口设计说明聊天接口采用POST方式请求体是一个标准JSON对象。messages数组里保存对话历史每一项包含role和content两个字段role可以取system、user或assistant分别表示系统设定、用户消息和助手回复。temperature控制生成随机性值越大回答越发散一般在0到1之间。返回时使用text/event-stream类型前端浏览器或客户端只有识别到这种媒体类型才会以流式方式处理响应。这个接口不返回完整JSON如果需要兼容非流式客户端可以再提供一个普通接口做兜底但第一版建议先专注跑通流式。6. 手机端核心流程拆解与代码实现6.1 创建uni-app项目假设你已经通过前面的命令创建好项目并执行了npm run dev:h5。在这里我们会新建一个聊天页面页面结构包含三块消息展示区、底部输入框、发送按钮。消息列表用scroll-view处理滚动输入框用原生input组件底部按钮用button。创建好的项目里页面目录通常是src/pages。为了保持结构清晰可以在src/pages下新建一个chat目录并在pages.json里注册页面路径。如果还不熟悉页面注册规则可以参考uni-app官方文档中关于pages.json的说明。6.2 聊天页面布局下面的代码是一个最简可用的聊天页面模板核心目标是把用户消息和助手消息以左右气泡形式展示出来。样式部分没有做过多的美化重点在于业务逻辑能跑通。!-- 文件路径src/pages/chat/chat.vue -- template view classchat-page scroll-view classmessage-list scroll-y :scroll-topscrollTop view v-for(msg, index) in messages :keyindex classmessage-row :classmsg.role user ? user : assistant view classbubble{{ msg.content }}/view /view /scroll-view view classinput-bar input v-modelinputText placeholder说点什么... confirm-typesend confirmsend / button :disabledloading clicksend发送/button /view /view /template script setup import { ref } from vue; import { fetchChat } from /api/chat; const messages ref([]); const inputText ref(); const loading ref(false); const scrollTop ref(0); async function send() { const text inputText.value.trim(); if (!text || loading.value) return; messages.value.push({ role: user, content: text }); const assistantMsg { role: assistant, content: }; messages.value.push(assistantMsg); inputText.value ; loading.value true; // 发送消息历史时去掉最后一条尚未生成完的assistant消息 const history messages.value.slice(0, -1); try { await fetchChat(history, (chunk) { assistantMsg.content chunk; scrollTop.value 99999; }); } catch (error) { assistantMsg.content 请求出错${error.message}; } finally { loading.value false; } } /script style scoped .chat-page { display: flex; flex-direction: column; height: 100vh; } .message-list { flex: 1; padding: 20rpx; box-sizing: border-box; } .message-row { display: flex; margin-bottom: 20rpx; } .message-row.user { justify-content: flex-end; } .bubble { max-width: 80%; padding: 16rpx 24rpx; border-radius: 16rpx; background-color: #f2f3f5; word-break: break-word; } .message-row.user .bubble { background-color: #4a90d9; color: #ffffff; } .input-bar { display: flex; padding: 16rpx; border-top: 1px solid #eee; background-color: #ffffff; } .input-bar input { flex: 1; height: 72rpx; border: 1px solid #ddd; border-radius: 12rpx; padding: 0 20rpx; } .input-bar button { margin-left: 16rpx; } /style页面逻辑不算复杂。send方法先把用户输入推入messages数组再创建一个内容为空的助手消息也推入数组随后把除最后一条助手消息之外的历史记录发给后端。后端每返回一个文本片段就往助手消息的content后面追加因为Vue的响应式绑定界面会实时更新。这里有一个非常容易踩的坑如果你把完整messages数组发给后端最后一条消息可能是角色为assistant但内容为空的占位消息模型会把它当成一条异常输入。所以发送前必须用slice(0, -1)去掉它。本文代码已经处理了这个问题但你自己从零写的时候很容易漏掉。6.3 请求封装与SSE解析在src/api/chat.js中封装请求逻辑。这里使用浏览器fetch的ReadableStream能力逐段读取后端返回的数据。本示例适配H5端因为H5运行在浏览器中具备完整fetch能力如果你要跑在App端建议之后将后端改造成WebSocket再用uni.connectSocket接收消息。// 文件路径src/api/chat.js const BASE_URL http://localhost:8000; export async function fetchChat(messages, onMessage) { const response await fetch(${BASE_URL}/api/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ messages, temperature: 0.7 }), }); if (!response.ok) { throw new Error(请求失败${response.status}); } const reader response.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop(); for (const line of lines) { if (!line.startsWith(data:)) continue; const data line.slice(5).trim(); if (!data || data [DONE]) continue; const json JSON.parse(data); if (json.content) { onMessage(json.content); } } } }解析SSE的关键在于“按行拆包”。后端在返回数据时每条消息以空行分隔但网络传输过程中一个完整数据块可能会被拆成多个片段。技巧是维护一个buffer先按换行符拆分把拆出来的完整行拿出来处理最后一个不完整片段留在buffer里等下一次读取再合并。真正开发时还会遇到[DONE]标记它表示整个流式响应结束。代码里遇到这个标记直接跳过因为循环也会在reader.read()返回done后终止。如果后端在某次响应中同时返回多行数据这段代码也能按顺序依次解析不会丢数据。6.4 状态栏与安全区适配手机端页面布局还有一个常见问题消息列表顶部会被状态栏遮挡。浏览器环境下一般没有这个问题但打包成App后状态栏会占掉一部分屏幕高度。处理思路有两种一种是在pages.json里配置导航栏让uni-app自己处理状态栏高度另一种是自定义沉浸式状态栏在页面根节点上加上padding-top并用CSS变量env(safe-area-inset-top)预留安全区。建议第一版先用默认导航栏把状态栏问题交给框架处理集中精力调通聊天逻辑。后续如果要做自定义导航栏再统一处理安全区。状态栏适配是个典型的“看起来不重要、真机上很头疼”的问题所以这里单独提出来。7. 运行验证与联调7.1 启动后端并验证接口先把Ollama服务确保在运行然后在后端目录启动FastAPI应用。命令如下uvicorn main:app --host 0.0.0.0 --port 8000这里把--host设置成0.0.0.0是为了让手机通过局域网IP也能访问到后端而不是只能在本机访问。启动后在浏览器打开http://127.0.0.1:8000/docs可以看到FastAPI自动生成的接口文档这能帮助你快速测试接口参数。使用curl命令可以直接验证SSE流是否正常。终端里执行下面的命令如果能看到多行data:输出说明后端到模型服务的链路是通的。curl -N -X POST http://127.0.0.1:8000/api/chat \ -H Content-Type: application/json \ -d {messages:[{role:user,content:用一句话介绍你自己}],temperature:0.7}-N参数用于关闭curl的输出缓冲让流式内容尽快显示。如果这里没有任何输出第一步看Ollama服务是否运行第二步看终端里有没有报错日志。后端接口是整条链路的中间层先把这里跑通再排查前端问题。7.2 启动前端并模拟手机环境在my-ai-chat项目目录下执行npm run dev:h5浏览器会打开H5页面。为了模拟手机端效果可以用浏览器开发者工具的移动设备模式。此时在输入框里输入一句话点击发送消息区域应该能看到助手内容逐字出现。如果你手边有真机想用手机访问H5页面需要注意两点。第一手机和电脑要处于同一个局域网第二前端BASE_URL不能写localhost要改成电脑的局域网IP比如http://192.168.1.100:8000。同时后端启动时已经监听了0.0.0.0手机才能通过局域网访问到接口。7.3 判断功能是否成功一个聊天功能是否成功可以从三个维度判断。第一是“能聊起来”用户发送消息后模型返回正常中文回答内容没有截断第二是“能流式显示”文字不是等全部生成完才出现而是边生成边显示第三是“能维持上下文”连续问“我叫小明”再问“我叫什么”模型能记住前文。如果第一轮就失败优先看浏览器控制台和终端日志。浏览器控制台会显示请求失败或CORS报错终端日志会显示后端是否收到了请求、Ollama是否正常响应。不要一上来就改代码先定位是哪一层出了问题再对症处理。8. 常见问题与排查思路手机端AI项目跑起来之后涉及的工程问题比单纯写后端要多。下面列出开发过程中最高频的一些问题基本覆盖了从“网页能跑”到“手机能正常用”的差距。问题现象可能原因排查方式解决方案手机访问不到后端接口前后端不在同一局域网或后端只监听了127.0.0.1手机浏览器直接访问后端地址检查网络连通性后端启动加--host 0.0.0.0前端改用电脑局域网IP页面顶部内容被状态栏遮挡使用自定义导航栏时没有处理安全区真机截图确认遮挡区域配置默认导航栏或使用safe-area-inset-*留白开发工具CLI版本与手机端表现不一致项目依赖没有对齐HBuilderX与CLI版本存在差异对比npx uni -v和HBuilderX内置版本统一使用同一套工具链删除node_modules后重新安装App端无法用fetch读取流式数据App环境不是标准浏览器fetch能力有限查看App端控制台请求日志后端改WebSocketApp端使用uni.connectSocketSSE中文乱码解码时未按UTF-8处理检查响应头字符集前端使用TextDecoder(utf-8)后端确保UTF-8模型响应到一半中断Ollama负载过高或网络超时查看后端和Ollama日志降低并发调大httpx超时时间必要时换小模型验证码短信收不到通道限流、号码格式或接口分发问题查看短信服务商发送记录调用正规短信服务检查频率限制和签名模板这里特别要说一下“App端无法读取流式数据”的问题。本文示例代码用fetch实现SSE解析在H5端可以正常运行但打包成App后uni-app的App端并不是完整的浏览器环境fetch的流式读取能力在不同设备上表现不一致。更稳妥的做法是后端同时提供WebSocket接口App端用uni.connectSocket建立长连接收到多少数据就渲染多少数据。这是移动端聊天项目的常见选型不要等到测试阶段才发现。另一个容易被忽视的问题是“真机调试和模拟器行为不一致”。模拟器里页面正常真机上状态栏遮挡、键盘弹起把输入框顶走、网络请求被移动网络拦截这些情况都可能出现。建议从第一版开始就坚持真机联调真机出现的问题才是用户真正会遇到的问题。9. 最佳实践与工程建议9.1 安全边界与密钥管理一定要记住一个原则模型服务的API Key、内部接口地址、管理后台信息都不能出现在手机端代码里。即使是免费模型一旦密钥泄露别人可以拿你的Key去刷接口轻则消耗免费额度重则产生费用。正确方式是把所有外部依赖收敛到后端服务手机端只拿到一个短期的业务Token。如果你使用的是云端API建议在后端增加请求频率限制比如每个用户每分钟最多请求10次。免费额度不是无限额度不做限流的话一个异常客户端就可能耗尽整个项目的预算。Ollama本地部署虽然没有Key泄露风险但也要做访问控制避免局域网内其他设备直接调模型接口。9.2 上下文长度控制聊天项目上线后最明显的体验差异来自上下文管理。把所有历史对话都发给模型一是浪费Token二是超出模型窗口后直接报错。常见做法是只保留最近N轮消息比如10轮超过部分丢弃如果想保留更多记忆可以把更早的对话交给模型做摘要把摘要作为系统提示词的一部分。对于第一版滑动窗口截断已经足够。后续如果要做知识库问答可以把用户问题先召回相关片段拼进提示词再发给模型而不是把整本资料都塞进上下文。这个优化方向会让聊天质量有很大提升属于“从能用到好用”的关键一步。9.3 状态栏与安全区适配移动端页面与普通网页最大的区别之一就是状态栏和底部手势条。如果页面使用全屏沉浸式布局顶部状态栏会遮住内容底部手势条也可能遮住输入框。建议在开发阶段就统一封装一个“安全区容器”组件把env(safe-area-inset-top)和env(safe-area-inset-bottom)等系统变量集中管理。很多人在做“手机端显示状态栏”时只处理了高度忽略了聊天输入框被键盘顶起的问题。在scroll-view和输入框的布局上尽量使用flex布局让输入框固定在底部当键盘弹出时uni-app在不同平台上的表现也不一样需要根据平台做兼容。这些细节不会出现在后端接口设计里但对用户体验影响很大。9.4 日志与错误上报后端接口能工作只是起点线上出问题时如果没有任何日志排查会非常痛苦。建议在聊天接口中记录三类日志请求日志包含消息长度和模型名称错误日志包含异常类型和堆栈性能日志包含首包时间和总响应时长。这些日志不需要一开始做得很重靠Python的logging标准库就能满足。手机端同样需要错误日志。当用户反馈“发送后没反应”“回答到一半没了”如果前端没有任何上报开发者很难判断是接口报错、模型超时还是网络断开。第一版可以先把错误信息写入console同时弹窗提示后续再接入可观测性平台把关键日志统一收集起来。9.5 版本管理与团队协作手机端项目和纯后端项目有一个很大的不同前端代码要经过编译才能运行在真实设备上而编译工具链如果版本不一致很容易出现“我这能跑、你那不能跑”的情况。解决思路是统一开发工具和依赖版本项目里提交package-lock.json或pnpm-lock.yaml让团队成员安装同一套依赖。如果团队中有人用HBuilderX、有人用命令行CLI建议约定项目使用其中一种作为主链路避免混用导致构建结果不一致。H5端、App端、小程序端是同一套代码的多个编译目标也要在CI流程里分别构建验证。这套规范并不复杂但能省掉大量联调时间。10. 总结与后续学习方向这篇内容拆解的是一个免费AI聊天引擎手机端的完整链路。核心并不在于某个模型“效果多么好”而在于四个技术点能否串起来Ollama本地模型服务、FastAPI的SSE流式接口、uni-app的跨端聊天页面、以及手机端特有的状态栏与版本兼容问题。把这套链路跑通之后你已经具备了自己搭建AI聊天应用的基础骨架。下一步可以沿着几个方向继续深入。一是把前端通信方式从SSE换成WebSocket让App端的流式输出更稳定二是在后端加入用户体系让每个用户的消息和历史记录互相隔离三是引入向量数据库给聊天引擎加一个知识库能力。每个方向都能让这个“免费AI聊天引擎”从一个Demo变成可上线的产品。如果你正在计划自己的手机端AI项目建议先用本文的代码跑通最小链路再围绕实际业务去调整模型选择和交互方式。本地模型和云端API各有优势没有绝对的好坏只有适不适合当前场景。把基础链路吃透后续换模型、加功能都会轻松很多。