企业官网建设流程全解析

简介：这是一份面向小程序开发者的物体识别全栈项目资料，将微信小程序前端与腾讯云轻量应用服务器后端相结合，并引入 Django 服务、Anaconda 环境及 YOLOv3 模型，帮助读者打通从界面交互到云端推理的完整链路。压缩包内共 3832 个文件，大小约 414.62MB，以 JavaScript、TypeScript 源码和 Markdown 文档为主体，同时包含 JSON/YAML 配置、许可证文件以及大量 npm 依赖，还配有微信开发者工具安装程序与 YOLOv3 模型压缩包，便于直接搭建运行环境与快速启动工程。目前已有 482 人学习下载。借助其中的工程目录、依赖清单和模型文件，开发者可以快速理解小程序调用云服务器接口、后端处理请求并调用深度学习模型的全过程。整套资料适合具备一定编程基础、希望上手 AI 应用开发的读者作为实践参考与项目模板。

1. 小程序物体识别：算法能跑通，先问问服务器同不同意

一个物体识别小程序，前端再怎么折腾，最后都要落到一个后端接口上：接收图片、跑模型、回传坐标和类别。我见过不少开发者的姿势是——本机跑通就以为部署没问题，结果真机一预览，请求直接失败，然后开始怀疑算法写错了。其实卡住你的大概率不是识别模型，而是底下那台腾讯云轻量云服务器没搭对。轻量服务器便宜、方便，但镜像选错、端口没放行、域名没配 HTTPS，任何一个环节都能让你在下午三点对着开发者工具怀疑人生。这里完整记录一遍我用腾讯云轻量云服务器，把一套小程序物体识别后端从压缩包跑通到真机可用的全过程，适合刚买服务器不知从哪下手的，也适合想快速复现这套部署的熟手。

2. 装前准备：轻量云服务器选型与基础环境四件套

2.1 规格怎么选：2核4G起步，别贪小便宜

选轻量服务器第一个问题就是规格。物体识别后端跟静态网页不一样，图片上传、模型推理、数据库读写几个动作同时发生时，内存和 CPU 都很敏感。我当时用的是 2核4G 的腾讯云轻量云服务器，5M 带宽，50G 系统盘。说下为什么这样选：

系统镜像我选了 Ubuntu 22.04（64 位），CentOS 7.9 也很常见，差别主要在包管理命令：Ubuntu 用 apt，CentOS 用 yum。有一点要注意：Ubuntu 22.04 自带 Python 3.10，但没有自带 Node.js，后面得通过 NodeSource 或 nvm 安装。不建议选带「宝塔面板」的预装镜像，除非你确实熟悉面板管理——面板和自装环境双轨并存时，很容易出现 Nginx 被面板抢占端口、配置不生效的怪问题。

提示：轻量服务器的流量包按自然月计算，跑模型训练或大量图片测试前先看一眼剩余流量，免得月底被限速。

2.2 登录与安全组：先放行端口，再谈安装

拿到服务器后，第一件事不是装环境，而是去控制台的防火墙/安全组里确认端口放行规则。默认情况下轻量服务器只开放 22（SSH）、80（HTTP）、443（HTTPS）就够用了；MySQL 的 3306、Node 服务的 3000 这类端口如果暴露到公网，会被全网扫描，安全风险极大。我的做法是：公网只放 22/80/443，服务之间走本机回环地址通信，不让 3306 和 3000 出现在公网防火墙上。

SSH 登录命令：

# 用 root 或你创建的管理员用户登录 ssh -i ~/keys/my_server_key.pem root@<服务器公网IP> # 登录后第一时间更新系统包索引 sudo apt update && sudo apt upgrade -y

说明：-i参数指定密钥文件，如果创建服务器时选了密码登录，可以省略-i直接回车后输密码。密钥方式比密码少一层爆破风险，我习惯用密钥。apt update会刷新软件源，这一步慢是正常的，国内网络环境下可以用镜像源加速，但改sources.list之前先备份原文件。

登录后可以用nproc、free -h、df -h三连确认机器规格：分别看核数、内存和磁盘。刚开的机器如果没看到预想配置，及时在控制台确认实例规格，别等到环境装完才发现买错了。

2.3 环境四件套：Nginx、Node.js、MySQL、Python 的安装顺序

这套部署用到的基础环境是：Nginx（反向代理 + HTTPS 终止）、Node.js 18+（跑 API 网关和业务逻辑）、MySQL 8.0（存用户和识别记录）、Python 3.10（跑识别模型）。其中 Python 3.10 在 Ubuntu 22.04 自带，Node.js 用 NodeSource 源安装，MySQL 用 apt 安装。

Node.js 与 Nginx 一起装：

# 安装 NodeSource 提供的 Node.js 18.x curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash - sudo apt install -y nodejs node -v # 确认版本 v18.x # 安装 Nginx sudo apt install -y nginx sudo systemctl enable --now nginx nginx -v # 确认 Nginx 版本

这里特意没用 apt 自带的旧版 nodejs 而走 NodeSource，是因为 Ubuntu 源里的 Node 版本偏旧，后端的 Express 等新依赖可能要求 Node 14+ 甚至更高。装完node -v显示 v18.x 就说明源生效了。Nginx 用systemctl enable --now让它开机自启并立即运行，后面做反代时还要回来改它的配置文件。

MySQL 在 Ubuntu 22.04 的默认源里就是 8.0 版本：

sudo apt install -y mysql-server sudo systemctl enable --now mysql # 初始化安全配置：设置 root 密码、移除匿名用户 sudo mysql_secure_installation mysql --version # 确认版本 8.x

mysql_secure_installation是个交互脚本，建议一路按推荐选：设置 root 密码、移除匿名用户、禁止 root 远程登录。最后一条很重要：root 只需要存在于本机，后续会单独建一个给后端专用的账号，避免代码里泄露的密码直接暴露 root。

Python 这边，Ubuntu 22.04 自带 Python 3.10，只需要再装 pip 和图像处理的系统依赖。这些依赖是 OpenCV/Pillow 读取图片时的底层库，漏了会在后面 import 阶段报错：

sudo apt install -y python3-pip python3-dev # 图像处理基础库，缺失会导致 Pillow/OpenCV 安装失败或运行报错 sudo apt install -y libgl1 libglib2.0-0 libsm6 libxext6 libxrender-dev python3 -V # 确认 3.10.x

这个坑我踩过不止一次：Pillow 编译需要 zlib 和 libjpeg，OpenCV 需要 libgl1。如果你发现 pip 安装超时或运行时报libGL.so.1缺失，回来检查这三行里的 lib 包是否装上。到这里服务器底子就打好了，下面把压缩包里的后端服务跑起来。

3. 后端落地：把识别服务从压缩包跑成可调用的接口

压缩包拿到手，解压前先想清楚目录。我这套结构里有两个服务：Node.js 的 API 网关负责收图片、转发识别请求、回结果给小程序；Python 的识别进程负责加载模型、做推理。两个服务通过本机回环地址通信，这样后续出问题时，日志能分得清是业务层还是模型层的问题。

3.1 目录规划与解压：中文文件名里的暗坑

把压缩包上传到服务器后，先建工作目录再解压。这里有个踩过几次的坑：Windows 下打的 zip，内部文件名可能是 GBK 编码，解压出来中文文件名会乱码，后面引用路径会报「文件不存在」。我的做法是用 unzip 解压，如果乱码就改用 7z 按 UTF-8 方式重新解压。

# 上传压缩包到 /home/ubuntu/ 后执行 mkdir -p /home/ubuntu/recognition-app cd /home/ubuntu/recognition-app unzip ../小程序物体识别开发（腾讯云轻量云服务器搭建).zip # 如果出现乱码，改用 7z 以 UTF-8 方式解压 sudo apt install -y p7zip-full 7z x ../小程序物体识别开发（腾讯云轻量云服务器搭建).zip -o./ -mcp=CP936

解压后先看一眼目录结构，确认里面是完整的服务端代码而不是只有文档：

cd /home/ubuntu/recognition-app find . -maxdepth 2 -type d | sort

这里按文件后缀确认三类东西：package.json（Node 服务）、requirements.txt（Python 依赖）、数据库初始化 SQL。三样都在再往下走。如果压缩包里只带说明文档没带代码，那就按文档里的架构步骤手工实现服务，本文后续的部署思路依然适用。多数情况下包里会带可直接运行的工程，我们按带工程的情况处理。

3.2 初始化数据库：建库、授权一次做完

数据库初始化我单独写成一个 SQL 脚本，而不是让 Node 服务启动时自动建表。原因很简单：自动建表方便但有风险，服务一旦用错账号建出错误结构，后面改表代价大。手动初始化让结构变成可见、可控的。

-- init.sql CREATE DATABASE IF NOT EXISTS object_scan DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 给后端专用账号，限定只能从本机连接 CREATE USER IF NOT EXISTS 'app_user'@'localhost' IDENTIFIED BY '这里写一个不小于12位的强密码'; GRANT ALL PRIVILEGES ON object_scan.* TO 'app_user'@'localhost'; FLUSH PRIVILEGES; USE object_scan; -- 识别记录表：一次上传识别对应一条 CREATE TABLE IF NOT EXISTS scan_records ( id INT AUTO_INCREMENT PRIMARY KEY, image_url VARCHAR(255) NOT NULL COMMENT '图片访问路径', result_json JSON NOT NULL COMMENT '识别结果，类别与坐标', openid VARCHAR(64) DEFAULT '' COMMENT '小程序用户标识', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

执行方式：

mysql -uroot -p < init.sql

参数说明：utf8mb4 是必然选择，识别结果里的中文类别名（比如「猫」「狗」「杯子」）只有 utf8mb4 才能完整存下，用旧的 utf8_general_ci 在插入 emoji 或扩展字符时会报Incorrect string value。result_json用 JSON 类型而不是 TEXT，是让 MySQL 8 能对 JSON 字段做校验和索引，后续按类别查询会省很多事。openid字段留给从小程序会话里取到的用户标识，不放也能跑，但有了它做「我的识别记录」列表会方便很多。

执行后验证表结构：

mysql -uapp_user -p -e "USE object_scan; SHOW TABLES; DESC scan_records;"

这里特意用app_user而不是 root 跑验证，顺手确认授权没有问题。如果报 Access denied，回头检查 init.sql 里的 'localhost' 是否写成了 '%'，后端连库的授权问题大多是主机范围写错。

3.3 安装依赖与启动：Node 网关 + Python 识别进程

依赖分两边装：先装 Node 端的 package.json 依赖，再装 Python 端的 requirements.txt。顺序上有讲究——先装 Python 依赖再启动 Node，因为 Node 启动后要探测 Python 识别服务是否活着，识别服务没起来，Node 会把探活失败写进日志，让你误以为是网关的问题。

cd /home/ubuntu/recognition-app/server-node # 路径按解压后的实际结构调整 npm install --production cd /home/ubuntu/recognition-app/recognition-py pip3 install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

pip 参数说明：-i指定了国内 PyPI 镜像源，因为部分依赖比如 opencv-python 体积大，默认源在部分网络环境下很容易超时。镜像源只影响下载速度，不影响依赖行为。如果你是内网环境访问不了外网源，把-i参数换成你内网搭的 PyPI 源地址即可。

两个服务都要前台试跑一次：

# 终端1：启动识别服务，默认监听 127.0.0.1:5000 cd /home/ubuntu/recognition-app/recognition-py python3 app.py # 终端2：确认识别服务在监听后，启动 Node 网关 cd /home/ubuntu/recognition-app/server-node node app.js # 默认监听 127.0.0.1:3000

注意两个服务都绑127.0.0.1而不是0.0.0.0，这是刻意的：它们只服务于本机内部的 Nginx 反向代理，不直接暴露公网。绑0.0.0.0再加上控制台放行端口，等于把未鉴权的识别接口公开给全网，流量会被扫、被刷，这是部署事故而不是配置风格问题。

前台试跑验证的是代码和依赖没问题。看到类似listening on 5000和API gateway on 3000的日志，说明可以进入托管环节。如果 Python 进程秒退，把最后 20 行报错贴出来检查，90% 是缺系统依赖或 requirements 版本冲突——前者回到 2.3 节补 apt 包，后者用pip3 list看关键库版本再锁定。

3.4 PM2 托管：进程守护和开机自启一次配齐

前台跑通之后，马上面对一个现实问题：SSH 一断，进程就没了。生产环境不能这么干。我用 PM2 托管两个进程，并把服务注册为开机自启。

sudo npm install -g pm2 cd /home/ubuntu/recognition-app/server-node pm2 start app.js --name api-gateway cd /home/ubuntu/recognition-app/recognition-py pm2 start app.py --name object-recognizer --interpreter python3 pm2 save pm2 startup

参数说明：--name给进程起别名，之后pm2 logs api-gateway就能按名字查日志。--interpreter python3是显式指定解释器，防止服务器存在多个 Python 版本时 PM2 取了错误的那个。pm2 save把当前进程列表存成快照，pm2 startup生成的 systemd 服务会在开机时恢复这个快照——这两条缺一不可，只执行其中一条的话，重启服务器后进程不会自动回来。

验证两条命令：

pm2 status # 两个进程都应处于 online 状态 pm2 logs object-recognizer --lines 20 # 看识别服务启动日志

这里还有一个熟手会做的事：把模型加载放进识别服务启动阶段，并打印加载耗时。如果日志显示模型加载耗时 5 秒以上，说明后续每次请求第一次推理都会卡较长时间，建议让识别服务启动时预加载模型，或者干脆保持 PM2 常驻不重启。这个习惯会在第 5 章排 502 问题时救你一命。

4. 对外上线：Nginx 反代和 HTTPS 合法域名一次配齐

后端两个服务都在本机跑起来了，但小程序不能直接请求127.0.0.1。小程序平台的 request 请求有域名白名单机制，而且线上环境强制要求 HTTPS。所以下一步是用 Nginx 把本机 3000 端口的网关服务代理到 80/443，再配上证书。

4.1 Nginx 反向代理：一个 server 块搞定 API 与上传大小

我直接改默认站点配置，不搞散装 conf。新建/etc/nginx/sites-available/recognition.conf，然后软链到 sites-enabled，以后改配置还能留个可回溯的文件。

# /etc/nginx/sites-available/recognition.conf server { listen 80; server_name api.example.com; # 替换成你的实际域名 # 小程序端上传图片走这里，注意大小限制 client_max_body_size 10m; location /api/ { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 60s; } }

说明：client_max_body_size 10m是给小程序上传图片留的余地。Nginx 默认是 1m，我最初没改这行，小程序端上传一张 2MB 的照片直接 413，排查了半天才发现是 Nginx 拦的。location /api/匹配所有以/api/开头的请求并转发到 Node 网关。proxy_set_header四行是反代的标准头，X-Forwarded-Proto尤其重要——否则后端要判断请求是 HTTP 还是 HTTPS 时，拿到的一律是 http。proxy_read_timeout 60s是因为首次推理如果模型冷启动会超过默认的 60s 超时，这里调大一点，但超过 60 秒说明是模型或机器性能问题，该查的是性能而不是等。

启用配置：

sudo ln -s /etc/nginx/sites-available/recognition.conf /etc/nginx/sites-enabled/ sudo nginx -t && sudo systemctl reload nginx

nginx -t会先检查语法，过了再 reload。这一步如果报 server_name 冲突，说明之前的默认站点还在监听 80，去 sites-enabled 里把 default 软链删掉再 reload。

4.2 HTTPS 证书：acme.sh 申请与全站跳转

证书方案我用 acme.sh 申请 Let's Encrypt 的免费证书，续期脚本自动做，很适合个人开发小程序。申请前先把域名解析 A 记录指向服务器公网 IP，解析生效后再执行：

curl https://get.acme.sh | sh -s email=your_email@example.com # 申请证书并安装到 Nginx 目录 ~/.acme.sh/acme.sh --issue -d api.example.com --nginx ~/.acme.sh/acme.sh --install-cert -d api.example.com \ --key-file /etc/nginx/certs/api.example.com.key \ --fullchain-file /etc/nginx/certs/api.example.com.pem

--issue --nginx模式会让 acme.sh 临时修改 Nginx 配置完成域名验证，比手动放验证文件省事。--install-cert的两个--file参数决定了证书最终落在哪里，我习惯放到/etc/nginx/certs下并统一按域名命名，方便后续续期脚本覆盖。然后再补充 443 的 server 块，加一个 80 跳 443 的规则：

server { listen 80; server_name api.example.com; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name api.example.com; ssl_certificate /etc/nginx/certs/api.example.com.pem; ssl_certificate_key /etc/nginx/certs/api.example.com.key; ssl_protocols TLSv1.2 TLSv1.3; client_max_body_size 10m; location /api/ { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 60s; } }

ssl_protocols写了 TLSv1.2 和 TLSv1.3：前者兼容老手机，后者保证新设备和安全评分。改完nginx -t再 reload，浏览器访问https://api.example.com/api/health能返回 JSON 就说明 HTTPS 链路通了。

4.3 小程序合法域名：request 和 uploadFile 都要配

后端就绪，最后卡在小程序平台这一侧。在小程序管理后台的「开发设置 - 服务器域名」里，把 request 合法域名填成https://api.example.com，uploadFile 合法域名也填同一个域名。小程序端上传图片走的是 uploadFile 接口，有些人鉴权接口域名配了，上传域名没配，真机上传时报url not in domain list，实际就是这里少配了一条。

开发阶段有个临时手段：小程序开发者工具的「详情 - 本地设置 - 不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书」勾上后，可以拿本机 IP 联调。这个勾选只对工具里的模拟器有效，真机预览依然走域名校验。我一般建议：开发期勾上，上真机前务必去掉勾选并按真实域名自测一遍，以真机为准。

注意：小程序平台要求的合法域名必须是 HTTPS，且证书在平台侧校验时需要完整链路。用 acme.sh 装的证书默认是完整的 fullchain，没问题；有些免费证书只给了单张证书文件没有中间证书，平台会校验失败，表现为「证书无效」。

5. 常见问题与避坑：真机跑不通，先查这五个地方

我把部署这套环境过程中实际遇到过的问题整理成五条，按「现象 → 原因 → 解决」的顺序记录，覆盖从域名白名单到进程管理的绝大多数故障面。如果你在照着流程走，强烈建议把这些结论存进部署文档。

5.1 开发者工具正常，真机预览全部请求失败

现象：模拟器和开发者工具里接口返回值正常，一旦切到真机预览或体验版，所有请求报错，错误信息类似request:fail或url not in domain list。

原因：两条。一是开发者工具勾选了「不校验合法域名」，模拟器环境帮你跳过了域名白名单，真机不走这个开关；二是管理后台的 request 合法域名与代码里实际请求的域名不一致，比如代码请求用了 IP 或者 http，而白名单只配了 https 域名。

解决：先在小程序管理后台把 https 域名（不含路径）加进 request 合法域名和 uploadFile 合法域名，然后去掉开发者工具的跳过校验勾选，重新编译。其次检查代码里wx.request的 url 是不是完整的 https 域名，确认没有写死本机 IP。最后看证书链：浏览器打开域名确认地址栏锁标识正常，再用在线工具查证书链完整度——中间证书缺失是平台侧校验失败的常见原因。

5.2 图片上传报 413，服务端日志里什么都没有

现象：小程序端wx.uploadFile上传图片一直失败，回调里 statusCode 为 null；Nginx 的 access log 里能看到413 Request Entity Too Large。

原因：Nginx 默认client_max_body_size只有 1m，手机拍的照片普遍在 2MB 以上，请求体在进入 Node 服务之前就被 Nginx 挡掉了。有些项目后端 bodyParser 也设置了 1mb 限制，两处都要查。

解决：Nginx 的 server 块里加client_max_body_size 10m;，同时确认后端 body 解析器的限制不低于这个数。Node 的 Express 项目里检查 express.json 的 limit 参数，默认是 100kb，必须显式调大，否则即使过了 Nginx 也会在 Node 层报 413。改完记得nginx -t && systemctl reload nginx，并让 Node 进程重启一次。

5.3 接口返回 502 Bad Gateway，PM2 里进程却显示 online

现象：访问/api/下的接口偶尔 502，频繁出现在第一张图上传时，后续请求恢复。PM2 里 Node 进程 status 是 online，日志没有异常。

原因：Nginx 把请求转发给 127.0.0.1:3000，但 Node 网关启动后还没完成对 Python 识别进程的探活，或者 Python 进程首次推理时模型加载耗时超过了 Nginx 的proxy_read_timeout。Node 进程虽然在线，但它依赖的下游识别进程没就绪或超时，Nginx 拿不到有效响应就返回 502。

解决：分两层处理。第一层，确认 Node 启动时对识别进程的探活逻辑：如果探测失败要快速失败重启，而不是傻等。第二层，把 Nginx 的proxy_read_timeout调到 60s，同时让 Python 进程在启动阶段预加载模型到内存，而不是等到首个请求才加载。这样 502 只剩一种可能——模型真的崩了，看pm2 logs object-recognizer就能定位，而不是玄学。

5.4 MySQL 报 Access denied，代码配置看着没问题

现象：Node 服务启动后，日志里数据库连接报错Access denied for user 'app_user'@'localhost'，但用 mysql 客户端在服务器本机用同样账号能连上。

原因：授权范围和你连接时的来源主机匹配不上。init.sql 里写的是'app_user'@'localhost'，但 Node 服务连接串里如果写的是127.0.0.1，MySQL 授权表里这两个主机名是不同条目，匹配不上就拒绝。另外 MySQL 8 默认认证插件是caching_sha2_password，旧版 Node 驱动不兼容也会报错。

解决：统一来源写法。要么连接串写 localhost，要么 init.sql 里同时授权'app_user'@'127.0.0.1'。Node 项目里我用 mysql2 驱动而不是 mysql 老包，因为 mysql2 原生支持caching_sha2_password认证。改完授权记得FLUSH PRIVILEGES。

5.5 请求返回 CORS 跨域错误，curl 却正常

现象：在开发者工具或网页里直接请求接口，浏览器控制台报 CORS 错误，但用 curl 访问接口返回正常。

原因：小程序端的wx.request本身不受浏览器 CORS 限制，这个报错通常是在网页端测试接口或某些调试工具里出现的。Nginx 反代到后端后，后端响应头里缺少Access-Control-Allow-Origin，浏览器就拦截了。

解决：如果确认只需要服务小程序，忽略 CORS 即可，因为小程序没有同源策略。如果还要在网页端调，后端统一在响应头加三个字段：Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers，并处理 OPTIONS 预检请求。我习惯在后端中间件里统一加，而不是 Nginx 层，这样后续鉴权逻辑也能统一控制。

6. 装完怎么验证跑通：一条从服务器到真机的检查链

到这里整套服务已经跑起来了，但「能跑」和「跑通」是两回事。我给自己定了一套验证流程，每次部署完都强制走一遍，顺序固定：先验证服务器内部链路，再验证公网链路，最后用小程序的真实上传接口做端到端验证。每一步的失败范围都能收敛到一层。

第一步，在服务器本机打两个服务的健康检查接口：

curl -s http://127.0.0.1:3000/api/health curl -s http://127.0.0.1:5000/health

两个接口都要返回 JSON，比如{"code":0,"msg":"ok"}这类结构。这一步验证的是进程本身没问题。如果 3000 通了但 5000 不通，问题一定在 Python 识别进程，回 3.4 节看 PM2 日志。

第二步，验证 Nginx 到后端的链路：

curl -s http://127.0.0.1/api/health

这里走的是 80 端口反向代理。通了说明 Nginx 配置生效。不通就nginx -t查语法，再curl -v看详细请求头，确定请求到底卡在哪一层。

第三步，验证公网 HTTPS：

curl -s https://api.example.com/api/health

这一步同时验证 DNS 解析、证书有效性、443 端口放行。curl 报证书错误就说明证书没装对或域名解析不对；报超时则八成是公网防火墙没放行 443。

第四步，用一张本地图片完整走一遍识别：

curl -s -F "file=@test_cat.jpg" https://api.example.com/api/scan \ | python3 -m json.tool

-F参数按 multipart/form-data 方式提交，模拟小程序wx.uploadFile的请求格式。返回的 JSON 里应当包含类别名和置信度，比如{"code":0,"data":{"objects":[{"label":"cat","confidence":0.92}]}}。这步通过，说明图片上传、模型推理、结果返回全链路可用。

最后一步才轮到小程序：真机预览，关闭开发者工具的跳过域名校验，在页面里选一张图上传，等识别结果渲染出来。我在这里有个习惯：真机验证时打开调试面板看请求耗时，识别接口整体超过 3 秒就回去查模型加载和机器负载，而不是默认「算法就这样」。从那次 502 排查之后，每次部署完我都强制自己走一遍上面这套验证链——少了任何一步，后面补日志的时间都远大于验证所需的两分钟。希望这套安装流程能帮到你，少折腾一个下午。

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