企业官网建设流程全解析

1. 从桌面端到手机端：为什么我要给 AI 管家做移动入口

事情的起点很朴素：我在电脑上搭了一套 AI 管家服务，平时用浏览器打开一个本地页面就能对话、查资料、跑一些自动化任务。用着挺顺手，但问题也很明显——我不可能一直坐在电脑前。做饭的时候想让它帮我记个购物清单，躺床上想让它整理一下明天的日程，出门在外想让它查个东西，都得先开电脑，体验直接断档。

于是就有了这个项目：把原本跑在电脑上的 AI 管家，做成手机也能用的形态，最终装进 iPhone 主屏，点一下图标就能像原生 App 一样打开。听起来像是个小需求，但真动手做，会发现里面牵扯的东西不少：服务怎么暴露给手机、手机浏览器怎么稳定接收流式输出、iOS 上怎么让它看起来像个 App、网络环境怎么处理才不出岔子。

这篇文章就是把这整个过程完整拆一遍。适合两类人看：一类是已经在本地跑着某种 AI 服务、想扩展到手机上的朋友；另一类是对iPhone、nginx、SSE、REST、iOS这套组合感兴趣、想搞清楚它们怎么串起来的人。我不打算讲太玄的东西，重点放在“我实际怎么做的、为什么这么做、踩了哪些坑”。

先说结论性的判断：核心难点不在 AI 本身，而在“连接”和“呈现”这两件事上。连接指的是手机怎么稳定地访问到你电脑上的服务；呈现指的是在 iOS 的浏览器环境里，怎么让一个网页表现得像一个 App。把这两件事解决，剩下的都是细节。

2. 整体架构设计：先想清楚数据怎么流动

2.1 三种可选方案，我为什么选了反向代理这条路

把本地服务给手机用，思路无非三种。

第一种是直接把服务绑到局域网 IP 上，手机和电脑连同一个 WiFi，直接访问http://192.168.x.x:端口。这是最省事的做法，零配置，五分钟能跑通。但它的问题也很直接：一旦离开这个 WiFi 就用不了，而且很多 AI 服务的默认配置只监听127.0.0.1，你得改配置让它监听0.0.0.0，安全性上等于把服务摊开给整个局域网。

第二种是用内网穿透工具把本地端口映射到一个公网地址。好处是随时随地能访问，坏处是要依赖第三方服务，配置项多，而且流式输出经过中转时经常出问题——这一点后面讲 SSE 的时候会细说。

第三种是自己用 nginx 做反向代理，把后端服务统一收口到一个入口，再决定怎么对外暴露。我最后选的是这条。原因有三个：一是 nginx 能把多个后端服务（对话接口、静态页面、文件服务）整合到一个域名或端口下，管理起来清爽；二是它对 SSE 这类长连接的支持可以通过配置调优，比裸奔的服务稳定；三是这套配置我以后换环境、换设备都能复用，属于一次投入长期受益。

提示：如果你只是想在同一个 WiFi 下临时用用，第一种方案完全够。但只要你希望“出门也能用”或者“以后接更多服务”，建议一开始就上 nginx，不然后面迁移会很痛苦。

2.2 一张图说清楚请求链路

整个链路其实不复杂，我用文字描述一遍，你脑子里能画出图就行：

手机上的 Safari（或主屏图标打开的 Web App）发起请求，请求先到 nginx，nginx 根据路径判断这是要静态页面还是要后端接口，静态页面直接返回，接口请求转发给后面的 AI 服务。AI 服务处理完，如果是流式输出，就通过 SSE 一条条把内容推回来，nginx 负责把这些数据原样透传给手机。

这里有个关键点：nginx 默认会对响应做缓冲，也就是它想攒一批数据再发给你。这对普通网页没问题，但对 SSE 是致命的——你会看到手机上一动不动，等半天突然蹦出一大段，完全失去了流式的意义。所以后面配置里必须显式关掉缓冲，这是整个项目里最容易忽略、也最容易让人抓狂的一个点。

2.3 前端形态的选择：网页还是原生

既然目标是“装进 iPhone 主屏”，那前端到底做成什么？我考虑过三个方向。

原生 iOS 开发：体验最好，但要 Xcode、要开发者账号、要处理签名，对一个只想给自己用的小工具来说，投入产出比太低。

跨平台框架：比如用某种前端框架打包成 App，能上架也能本地装，但同样有构建、签名、证书这一堆事，而且调试链路变长。

Web App（PWA 思路）：就是做一个网页，然后利用 iOS 的“添加到主屏幕”功能，让它以独立窗口打开，看起来和原生 App 几乎一样。这是我最终选的方案。

选它的理由很实在：零安装成本、零签名烦恼、改完代码刷新就能看到效果。iOS 对“添加到主屏幕”的支持已经相当成熟，加上合适的 meta 标签，打开后没有浏览器地址栏，全屏显示，图标也是自定义的，日常使用根本感觉不出这是个网页。

3. 核心细节拆解：nginx、SSE、REST 各自扮演什么角色

3.1 nginx 反向代理配置的关键几行

nginx 在这个项目里干三件事：托管静态页面、转发 API 请求、透传流式响应。配置我简化成下面这样，你可以直接参考：

server { listen 8080; server_name _; # 静态页面 location / { root /path/to/your/webapp; index index.html; try_files $uri $uri/ /index.html; } # 后端 API 转发 location /api/ { proxy_pass http://127.0.0.1:5000/; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header Connection ''; # SSE 关键配置：关闭缓冲 proxy_buffering off; proxy_cache off; proxy_read_timeout 3600s; chunked_transfer_encoding on; } }

逐行说一下为什么这么写。

proxy_http_version 1.1是必须的，因为 SSE 依赖 HTTP/1.1 的长连接特性，用 1.0 会直接断。

proxy_set_header Connection ''这行看着奇怪，其实是为了清掉默认的Connection: close，让连接保持打开。很多人 SSE 连不上就是栽在这里。

proxy_buffering off是整个配置的灵魂。不关它，nginx 会攒数据，你的流式输出就变成了“憋大招”。

proxy_read_timeout 3600s是给长连接留足时间。默认 60 秒，AI 思考慢一点、回复长一点，连接就被掐了，手机上会看到莫名其妙的断开。

注意：proxy_cache off也要加上。有些 nginx 镜像默认开了缓存，SSE 这种一次性流被缓存住会出各种诡异问题。

3.2 SSE 为什么比轮询更适合 AI 对话

AI 对话有个特点：回复是逐字生成的。如果用普通 REST 请求，你得等它全部生成完才能拿到结果，用户盯着转圈圈等十几秒，体验很差。

SSE（Server-Sent Events）解决的正是这个问题。它是一条单向的长连接，服务器可以随时往客户端推数据。AI 每生成一个 token，就通过这条连接推给前端，前端立刻渲染出来，用户看到的就是“字一个个蹦出来”的效果。

它和 WebSocket 的区别在于：SSE 是单向的（服务器到客户端），基于普通 HTTP，实现简单，浏览器原生支持EventSource。AI 对话这种“我问一句、你答一长串”的场景，单向推送完全够用，没必要上 WebSocket 那么重的东西。

前端接收的代码大概长这样：

const source = new EventSource('/api/chat?q=' + encodeURIComponent(question)); source.onmessage = (event) => { if (event.data === '[DONE]') { source.close(); return; } appendToScreen(event.data); }; source.onerror = (err) => { console.error('SSE 连接异常', err); source.close(); };

这里有个坑要提前说：iOS Safari 对 SSE 的连接管理比较激进，页面切到后台、锁屏、网络切换，都可能把连接断掉。所以onerror里一定要做好重连或者提示，不能假设连接一直稳。

3.3 REST 接口的设计：简单、够用、别过度

后端接口我没搞太复杂，就一个 POST 接口接收问题，返回 SSE 流。参数用 JSON 传，字段就question、session_id两个。为什么不做成更“规范”的 RESTful 风格？因为这是自用工具，可读性和调试便利性比接口规范更重要。

不过有一点我坚持了：接口路径统一加/api/前缀。这样 nginx 里一条location /api/就能把所有后端请求收走，静态资源和接口泾渭分明，以后加新接口也不用改 nginx 配置。

4. 实操过程：从零到装进 iPhone 主屏

4.1 第一步：让服务在局域网里先跑通

别一上来就折腾外网，先在局域网里把链路走通。我的顺序是：

1. 确认 AI 服务本身能跑，本地浏览器访问正常。
2. 启动 nginx，确认静态页面能打开。
3. 手机连同一个 WiFi，访问http://电脑IP:8080，看页面能不能出来。
4. 在手机上发一条消息，看流式输出是否正常。

这一步能过，说明 nginx 配置、SSE 透传、前端接收都没问题。如果这一步就卡住，千万别急着往外网走，先把局域网调通，否则问题会叠加，排查起来要命。

查电脑 IP 的命令，Windows 用ipconfig，macOS 和 Linux 用ifconfig或ip addr。找到那个192.168.x.x的地址就行。

4.2 第二步：处理 iOS 的“添加到主屏幕”

这一步是让它“像 App”的关键。核心是在 HTML 的<head>里加几个 meta 标签：

<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover"> <meta name="apple-mobile-web-app-capable" content="yes"> <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent"> <meta name="apple-mobile-web-app-title" content="AI 管家"> <link rel="apple-touch-icon" href="/icon-180.png">

apple-mobile-web-app-capable设为 yes，打开后才会隐藏 Safari 的地址栏和工具栏，全屏显示。

apple-mobile-web-app-status-bar-style控制顶部状态栏样式，black-translucent会让内容延伸到状态栏下面，视觉上更沉浸。

apple-touch-icon是主屏图标的来源，尺寸建议 180x180，不然 iOS 会自动截取网页截图当图标，很难看。

然后在 Safari 里打开页面，点底部的分享按钮，选“添加到主屏幕”，图标就出现了。点它打开，就是一个独立窗口，和原生 App 的观感基本一致。

提示：图标和标题改完之后，如果主屏上还是旧的，删掉重新添加一次。iOS 对这两个东西有缓存，不会自动更新。

4.3 第三步：解决“出门也能用”的问题

局域网方案只能在家用。要出门也能访问，就得让服务有一个公网可达的入口。这里我不展开具体工具，只说思路和注意点。

核心是：把 nginx 的 8080 端口安全地暴露出去。无论你用什么方式，都要注意两件事。一是加访问控制，别让任何人都能连上你的 AI 管家，最简单的做法是在 nginx 里加一层 Basic Auth：

location / { auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd; # ...其余配置 }

用htpasswd命令生成密码文件即可。二是尽量走 HTTPS，因为 iOS 对非 HTTPS 的某些能力有限制，而且明文传输你的对话内容也不安全。

4.4 第四步：参数调优与实测记录

配置跑通不代表好用，我做了几轮调优，记录几个关键参数：

实测下来，关掉 buffering 之后，手机上的流式输出和电脑上几乎无差别，首字延迟在一秒以内。keepalive 调大之后，连续对话时不再频繁重建连接，体验顺滑很多。

5. 常见问题与排查技巧实录

5.1 SSE 连上就断、或者半天不吐字

这是最高频的问题，我整理成一张速查表：

我印象最深的一次，是手机上死活收不到流式内容，电脑上却一切正常。查了半天，最后发现是 nginx 配置里漏了proxy_set_header Connection ''，导致连接被当成短连接处理。这种问题不看日志根本想不到，所以养成看 nginx error.log 的习惯很重要。

5.2 主屏图标打开后还是带地址栏

多半是apple-mobile-web-app-capable没生效。检查两点：一是 meta 标签拼写有没有错，二是页面是不是通过 HTTPS 打开的。有些 iOS 版本对非 HTTPS 页面的全屏能力支持不完整，换成 HTTPS 后问题就消失了。

5.3 局域网能通、外网不通

先确认 nginx 有没有在监听正确的地址。如果配置里写的是listen 127.0.0.1:8080，那只有本机能访问，要改成listen 8080或listen 0.0.0.0:8080。再检查电脑的防火墙有没有放行这个端口。这两步能解决九成的“外网不通”。

5.4 我踩过的几个坑

第一个坑是图标尺寸。我一开始随便放了个 512x512 的图，结果主屏上显示被裁得只剩中间一块。后来换成 180x180 才正常。

第二个坑是中文标题。apple-mobile-web-app-title里写中文没问题，但要注意别太长，主屏图标下面显示不下会被截断，建议控制在四五个字以内。

第三个坑是缓存。改完前端代码，手机上死活看不到新效果，以为是配置问题，其实是 Safari 缓存。调试阶段建议在 nginx 里给静态资源加上Cache-Control: no-cache，省得反复怀疑人生。

6. 一些延伸想法和实际体会

这套东西跑稳定之后，我又顺手做了几件事。一是把文件服务也挂到同一个 nginx 下，手机上能直接看电脑里的文档；二是给接口加了个简单的历史记录，方便回看之前的对话；三是把图标和配色统一了一下，看着更像一个正经产品。

我个人在实际操作中的体会是：这类“把桌面服务搬到手机”的项目，技术难度其实不高，难的是耐心。难在你得一个个把连接问题、缓存问题、兼容问题磨平。每解决一个，体验就上一个台阶。等你某天躺在沙发上，点一下主屏图标就能和 AI 管家聊两句的时候，会觉得前面那些折腾都值。

最后分享一个小技巧：调试阶段，把 nginx 的日志级别调到info，能看到每个请求的详细流转，比盲猜快得多。等稳定了再调回warn，免得日志刷屏。这个习惯帮我省了至少一半的排查时间。