简介这套源码是一套面向PHP开发者、AI应用爱好者及网站二次开发者的轻量级在线聊天系统核心程序压缩后仅23KB部署门槛低适合快速搭建或集成到现有项目。系统内置用户管理、一键添加与修改接口、在线AI多模型聊天、文转图、图转图等功能并附带5种不同模式的API接口源码方便需要对外提供AI能力的开发者直接对接。资源包共22个文件以17个PHP业务文件为主体配合3个TXT说明或配置文档、1个HTML前端演示页面以及1个ZIP示例包整体体积约42KB目录结构精简便于按需查阅。目前已有208人学习下载适合想低成本拥有AI聊天站点或研究轻量级接口方案的开发者。通过源码可掌握接口动态配置与多模型切换的核心思路附带的对接demo还能帮助快速理解从页面提交到AI模型返回的完整调用过程。1. 一套PHP源码包如何撑起AI在线聊天网站系统这类 PHP 网站系统解决的需求很直接给你一个带前端聊天气泡、后端会话管理和 API 接口调用的完整站点上传到服务器填上模型 API Key就能跑起一个 AI 聊天网站。很多团队要的不是从零写代码而是把一套现成源码快速变成客服、内网知识助手或私人对话服务。这套代码的关键不在聊天 UI 有多炫而在 PHP 如何把用户消息、会话历史和模型 API 接口编排起来。反直觉的一点是越成熟的源码包越会把模型接口藏在后端前端只拿到一个业务返回这样既避免密钥泄露也方便你切换模型供应商。我下面按源码包里最常遇到的实现方式从请求链路、配置文件、LNMP 部署到 API 接口的流式封装逐层拆开让拿到同类型 PHP 源码的人能直接上手改配置也能定位到具体文件去改逻辑。2. 拆解AI聊天网站系统的核心链路PHP会话与API接口编排2.1 聊天请求在PHP里的流转路径从Session到模型网关一个成熟的 AI 在线聊天网站前端不会直接拿模型 API 的地址和密钥去发请求而是把请求统一交给 PHP 后端。常见流转路径是这样的用户在输入框提交消息JavaScript 把消息和会话 ID 通过 POST 提交到/api/chat这样的控制器控制器先做参数校验和内容安全检查再读取当前会话的历史消息拼装成模型需要的messages结构随后把这次请求交给模型网关服务类网关负责向实际的大模型 API 发请求并处理超时、限流和响应解析最后把模型返回的内容写回数据库或 Redis同时追加为新的历史消息前端拿到结果后渲染到页面。这个链路里最容易忽略的是“历史会话”的读写位置。有些源码把历史存在数据库的conversation_messages表里有些存在 Swoole Table 或 Redis 里两者对性能的影响差别很大。你拿到源码后第一件事不是去看模型调用而是先找message相关的模型类确认会话上下文是从哪读的。实际排错中我发现很多“答非所问”的问题并不是模型参数问题而是上下文拼接时把角色顺序打乱了或者把系统提示词丢掉了。另外一个值得留意的点是 API 接口的幂等设计。聊天页面在弱网下会多次重试提交如果不做请求去重用户会看到模型回复两次数据库里也会留下重复记录。常规做法是在前端生成一个client_msg_id后端在固定时间窗口内对同一个 ID 只处理一次这个逻辑通常写在中件间层或控制器构造函数里。2.2 对接大模型API的最小PHP代码先跑通一个非流式对话不管源码包用的是原生 PHP 还是 ThinkPHP、Laravel底层要跑通一个模型对话最可靠的方式就是封装一个类通过 cURL 发起 HTTPS 请求。下面这段代码是 OpenAI 兼容接口的最小实现绝大多数服务商都支持这种格式?php /** * 最小模型 API 调用示例 * 对应源码包中 app/service/ModelGateway.php 的简化版本 */ function chat(string $message, string $sessionId): string { $apiKey YOUR_API_KEY; $url https://api.example.com/v1/chat/completions; // 从 Session 或缓存中取出该会话的历史没有则初始化 $messages load_history($sessionId); $messages[] [role user, content $message]; $payload [ model gpt-4o-mini, // 后台配置的模型标识可多套切换 messages $messages, // 角色包含 system/user/assistant temperature 0.7, // 0~2越高越发散 max_tokens 1024, // 单次回复的最大 token 数 stream false, // 先关闭流式跑通整体链路 ]; $ch curl_init($url); curl_setopt_array($ch, [ CURLOPT_POST true, CURLOPT_POSTFIELDS json_encode($payload, JSON_UNESCAPED_UNICODE), CURLOPT_HTTPHEADER [ Content-Type: application/json, Authorization: Bearer . $apiKey, ], CURLOPT_RETURNTRANSFER true, CURLOPT_CONNECTTIMEOUT 10, CURLOPT_TIMEOUT 120, CURLOPT_SSL_VERIFYPEER true, ]); $response curl_exec($ch); if (curl_errno($ch)) { throw new RuntimeException(API 请求失败: . curl_error($ch)); } $httpCode curl_getinfo($ch, CURLINFO_HTTP_CODE); curl_close($ch); if ($httpCode ! 200) { throw new RuntimeException(API 返回 HTTP {$httpCode}: . $response); } $data json_decode($response, true); $reply $data[choices][0][message][content] ?? ; // 将用户消息和助手回复一起写回历史供下一轮使用 save_history($sessionId, $messages, $reply); return $reply; }这段代码把三件事压在一个函数里构造messages数组、发起 HTTP 请求、保存上下文。CURLOPT_SSL_VERIFYPEER一定要保持为true有些源码为了本地调试把它关掉生产环境容易招致中间人攻击。CURLOPT_CONNECTTIMEOUT建议设 10 秒防止模型服务端 IP 不通时整个 PHP 进程长时间挂住。CURLOPT_TIMEOUT设为 120 秒是因为某些长文本模型处理时间会超过 60 秒但你如果把stream打开这个值要重新考虑因为流式连接是持续占用超时判断要按空闲时间而不是总时长。2.3 必调参数与鉴权方式temperature、max_tokens和stream不同聊天源码对参数的暴露程度不一样有的后台只放三个选项有的给你完整的模型参数面板。下面这张表是几个直接影响回复质量和成本的参数也是你拿到源码后最需要确认是否对上位的配置项。参数作用范围典型值调整逻辑temperature影响随机性0.3 ~ 0.9客服和代码场景调低创意写作调高top_p影响候选词集合0.8 ~ 1.0和 temperature 不要同时猛调会让输出极端max_tokens限制单次回复长度512 ~ 2048后台往往用“最大回复字数”字段控制的是它presence_penalty鼓励引入新话题0.0 ~ 0.6多轮长时间对话里调高可减少重复词frequency_penalty惩罚高频词汇0.0 ~ 0.6和 presence 一起调能改善“嗯”“好的”这类词stream是否流式返回false / true聊天网站必须 true非流式只用于接口调试鉴权部分我见过最稳妥的做法是服务端持有主 Key然后在 PHP 里生成一个短期 token 给前端。前端请求/api/chat时带上这个 token后端先解析出user_id和session_id再结合当前用户是否允许调用该模型做二次判定。有些源码简化成前端无条件传一个api_key参数这种做法只适合本机 demo一旦暴露到公网别人可以直接盗刷你的模型额度。拿到源码后请优先搜索api_key出现在哪些文件里如果出现在public/static/js下这个包需要做权限改造。常见安全改法是所有模型请求统一走后端前端只传递消息内容和服务端下发的会话标识。在鉴权之外还需要关心 API 接口的返回结构。一些国内服务商虽然兼容 OpenAI 格式但错误返回体里的字段是自定义的比如error.response.message而不是error.message。你改配置后如果一直报“解析错误”先拉起接口文档对比choices这块的层级。为了减少这种差异网关层通常可以做一次统一封装把不同服务商的响应转换成项目内部标准结构再抛给上层控制器。3. 源码包目录分工与关键配置项找对入口再改代码3.1 一份典型的PHP源码目录结构长什么样拆开.zip后你应当先用文件管理器看顶层结构而不急着传到服务器。常见的 AI 聊天 PHP 源码即便框架不同目录设计也往往遵循“入口、应用、配置、外部库”的划分方式。下面是一份较典型的结构命名可能略有出入但角色一致. ├── app │ ├── controller │ │ ├── Chat.php # 聊天主控制器 │ │ ├── Auth.php # 登录/鉴权 │ │ └── Admin.php # 后台管理 │ ├── service │ │ ├── ModelGateway.php # 模型网关负责调 API 接口 │ │ └── SessionService.php # 会话管理 │ ├── middleware │ │ └── ContentCheck.php # 内容安全中间件 │ └── model │ ├── Conversation.php │ └── Message.php ├── config │ ├── app.php # 应用基础配置 │ ├── database.php # 数据库连接 │ ├── model.php # 模型服务商配置 │ └── session.php # 会话驱动配置 ├── public │ ├── index.php # 单入口文件 │ ├── static │ │ ├── js/chat.js │ │ └── css/style.css │ └── uploads # 用户上传文件目录 ├── runtime │ ├── logs │ ├── cache │ └── session ├── vendor # Composer 依赖 └── install ├── install.php # Web 安装引导 └── sql └── install.sql这个结构里有几个点需要你特别留意。public是 Web 根目录Nginx 必须在配置里把root指向它如果把 root 指到项目根目录别人就能直接下载config或.env文件。runtime目录必须允许 PHP-FPM 写否则日志和 session 写不进去系统会表现成一直登录失败。install目录在部署完成后要直接删除或改名否则有被重装覆盖数据库的风险。3.2 config配置文件里最值得改的字段不要一上来就改业务代码配置项才是你真正要动的部分。不同源码的配置文件名可能不同但字段含义大同小异。我整理了一份高频字段对照按优先级排列字段配置含义取值建议改错后果API_KEY模型服务商提供的密钥放在服务端不要提交到前端盗刷、额度耗尽API_BASE_URL模型接口的域名前缀以官方文档为准注意末尾不能多/v1接口 404DEFAULT_MODEL默认模型标识例如gpt-4o-mini或qwen-plus页面报模型不存在MODEL_LIST前端可选模型下拉列表与控制台实际开通的模型对齐选择后调用失败STREAM_OUTPUT是否开启流式输出聊天一般设为true用户看到一句话整体卡住MAX_HISTORY携带的历史消息条数10 ~ 20 条上下文太长费用和耗时上升SESSION_DRIVER会话存储方式file/redis/database多机部署时应使用 redisCONVERSATION_LIMIT每个用户会话数量上限100 ~ 500数据库无限膨胀REQUEST_RATE_LIMIT分钟级请求限制页面访问 30API 请求 60刷接口导致成本不可控API_BASE_URL是最容易出问题的一项。有些源码内部用rtrim($baseUrl, /) . /chat/completions拼接地址你在后台多写了一个/v1最终就会变成https://api.example.com/v1/v1/chat/completions。我建议在配置加载完成后用var_dump(trim(...))直接打出最终构造出来的 URL别靠猜。MAX_HISTORY决定一次请求携带多少轮上下文。数值太大token 成本会成倍增长数值太小多轮对话容易失忆。常规做法是取最近 8 到 15 条消息并且限制单条消息不超过 2000 字。好的源码会把超长历史做自动裁剪而不是直接截断因为硬切可能会切掉半句话。3.3 多模型切换与API接口路由的常见实现这类源码还有一个卖点后台可以切换多家模型服务商。实现方式通常不是写死每个请求的 URL而是维护一个网关配置在配置里注册多个服务商然后按当前站点设置的“默认服务商”去发请求。下面是一个常见的配置结构?php // config/model.php return [ default openai, // 当前启用哪个服务商 gateways [ openai [ api_key getenv(OPENAI_API_KEY), base_url https://api.example.com/v1, models [gpt-4o-mini, gpt-4o], ], local [ api_key getenv(LOCAL_API_KEY), base_url http://127.0.0.1:8000/v1, models [qwen2.5:7b], ], ], ];网关服务类里会先读取这份配置再根据外部传来的model参数决定去向。没有配置过的模型直接返回“模型不存在”而不是把请求发给默认服务商。这样做的真正好处是隔离异常某个服务商限流或调整接口后你只需要在default字段换一个值全站入口就切换走了。我一般会在测试环境里同时配两个服务商用一个“低成本模型”做冒烟测试确认配置类别和权限都没问题再切到正式模型。这样可以避免在做界面联调时消耗正式模型额度。如果你在源码里看到temp_model这种命名那通常是给管理员用的测试槽位和线上聊天主通道分开的不要混淆。4. 在LNMP上把AI网站系统跑起来环境、权限与排错4.1 环境准备PHP要求、扩展和伪静态规则这类 PHP 源码包一般在README.md或install目录里标注了最低 PHP 版本。目前较新的版本要求 8.1 或 8.2因为代码里会用到enum、readonly等新语法。如果服务器还是 PHP 7.4很多包会直接白屏或报语法错误。需要关注的扩展至少包括curl、openssl、json、mbstring、pdo_mysql、redis配合 Redis 会话驱动时。你可以在服务器上执行下面命令快速检查php -v php -m | grep -E curl|openssl|mbstring|pdo_mysql|redis缺扩展时用apt install php8.1-curl这类命令补装即可。但要注意不同 Linux 发行版的 PHP 包名不一样先确认自己的 PHP 版本再搜对应扩展包。Nginx 伪静态规则是部署的第二道关。多数源码使用单入口模式所有请求都进入public/index.php。下面是一份可以直接用的 Nginx 配置server { listen 80; server_name chat.example.com; root /data/www/ai-chat/public; index index.php index.html; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { fastcgi_pass unix:/run/php/php8.1-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~* \.(js|css|png|jpg|svg|woff2)$ { expires 7d; access_log off; } }try_files这一行的意思是如果磁盘上存在同名静态文件直接返回如果不存在就把请求交给index.php处理同时保留原始查询参数。这套规则对原生 PHP 和 ThinkPHP 都通用。root指向public目录而不是项目根目录这一步能挡住大量目录遍历风险。如果你发现后台路由一直 404第一件事就是看 Nginx 里是不是少了try_files或者遭遇了location /与location ~ \.php$的匹配冲突。4.2 部署步骤从上传源码到写入后台配置部署过程比写代码简单但每一步都可能拦你一下。我习惯按下面顺序操作每完成一步就做一次验证不要全部做完再查问题。# 1. 上传源码到目标目录且必须在项目根目录安装依赖 cd /data/www/ai-chat composer install --no-dev --optimize-autoloader # 2. 创建 .env 或 config.local.php从示例文件复制 cp .env.example .env vim .env # 3. 给运行目录写权限PHP-FPM 才能写日志和 session chmod -R 775 runtime uploads chown -R www-data:www-data /data/www/ai-chat # 4. 如果包带数据库迁移脚本则执行安装页或命令行迁移 php think migratecomposer install的作用是拉取vendor目录里的第三方依赖。很多从 Windows 上下载再打包进 zip 的源码会在压缩包里带上vendor但缺少一些 Linux 扩展对应的库。此时直接删掉vendor重新执行composer install更可靠。.env文件一定不要提交到版本库部署完成后可以用chmod 600 .env收紧权限。安装数据库时常见的是浏览器访问http://你的域名/install/install.php按引导填数据库名、用户名和密码。这一步要注意字符集选择务必选utf8mb4否则 Emoji 和中文人名会存成乱码。安装完成后立即删除install目录。有些源码的安装页在文件末尾会提示你“安装完成”但不会自动删除留给你的风险只能自己处理。4.3 高频故障排查白屏、500、空响应和超时实际跑起来后问题集中在下面几类。我把现象、常见原因和排查手段列成一张表方便你对着处理故障现象常见原因排查命令 / 方法访问首页直接白屏PHP 语法错误或缺少扩展php -l public/index.php看runtime/logs打开页面报 500目录权限或伪静态错误检查 Nginx error.logtail -f /var/log/nginx/error.log提交消息后一直“正在输入”流式响应被输出缓冲拦截在接口里输出前调用ob_end_clean()模型回复内容为空响应解析层级写错打印$data[choices][0]的原始 JSON请求模型接口超时服务器到服务商网络慢或 DNS 问题curl -I https://api.example.com看耗时API 报 401 / 403API Key 配置错误或权限不足核对.env中 Key 是否有多余空格后台登录成功但前端一直跳回登录页Session 目录不可写ps aux排查白屏时先开 PHP 错误显示在.env里临时把APP_DEBUG设为true或者直接修改php.ini里的display_errors On。上线前再把这些关掉否则日志会把数据库密码打出来。SSE 空响应是聊天场景里最讨厌的问题。即使接口代码正确Nginx 也可能对响应做缓冲导致前端迟迟收不到第一段文本。解决办法是第 5 章要讲的流式输出技巧同时在 Nginx 配置里为带X-Accel-Buffering: no的接口去掉代理缓冲。排查超时问题多留意 PHP-FPM 的request_terminate_timeout默认 30 秒对一些长文本模型根本不够用要改成 0 或在fastcgi.conf里单独给聊天接口设置更大的值。5. 进阶把AI网站系统的API接口封装成可复用的模型网关5.1 用PHP输出SSE流式响应聊天体验更接近官方客户端聊天网站如果每次都要等模型生成完再返回体验非常差。源码包到后期通常会支持 SSE 流式输出也就是服务端一边接收模型返回一边把数据块推送给浏览器。实现核心在于两点发出text/event-stream头以及禁掉中间层缓冲。下面是最小可用的流式发送封装?php function streamChat(string $message, string $sessionId): void { header(Content-Type: text/event-stream; charsetutf-8); header(Cache-Control: no-cache); header(X-Accel-Buffering: no); // 组装模型请求stream 固定为 true $payload build_payload($message, $sessionId); $ch curl_init($apiUrl); curl_setopt_array($ch, [ CURLOPT_POST true, CURLOPT_POSTFIELDS json_encode($payload), CURLOPT_HTTPHEADER [ Content-Type: application/json, Authorization: Bearer . $apiKey, ], CURLOPT_WRITEFUNCTION function ($ch, $chunk) { echo $chunk; ob_flush(); flush(); return strlen($chunk); }, ]); curl_exec($ch); curl_close($ch); }CURLOPT_WRITEFUNCTION会在每次收到数据块时被调用直接把原始 SSE 帧转发给浏览器。ob_flush和flush的作用是绕过 PHP 自身的输出缓冲让数据尽快到 Nginx。X-Accel-Buffering: no是告诉 Nginx 不要吞掉小块响应否则前端也要等攒够一定字节才触发onmessage。这条代码里的关键参数是build_payload必须设置stream true否则模型接口会把整段 JSON 一次性返回流式前端反而解析失败。5.2 给API接口加一层校验非法请求拦截在网关之前暴露在公网的聊天接口最怕被其他站点盗用或刷量。只靠前端按钮肯定不够我建议在网关入口处统一做三层校验请求频率、会话归属、内容安全。频率限制可以用 PHP 内置的session记录时间戳也可以用 Redis 的INCREXPIRE后者对集群部署更友好。# 校验你的接口是否按预期返回 429 限流响应 curl -i -s -X POST https://chat.example.com/api/chat \ -H Content-Type: application/json \ -H X-Session-Token: your-token \ -d {message:hello} \ -w \n耗时: %{time_total}s\n关注响应头里的HTTP/1.1 200和Content-Type就能判断 Nginx 和 PHP 链路是否正常。加上-i能看到原始头确认X-Accel-Buffering是否生效。接口验证时可以把max_tokens调到 10用最便宜的模型试通这样既不拖慢调试也不浪费额度。5.3 收尾技巧用联合接口实现模型故障自动降级如果你不只做演示还希望聊天接口的可用性更高我推荐一个轻量技巧在网关层写一个“故障降级”循环。当默认服务商返回 429、5xx 或连续超时自动把请求切到第二个服务商而不是直接告诉用户“模型服务不可用”。实现思路很简单把各个服务商封装成同一个接口用循环把可用项依次尝试一遍。?php function chatWithFallback(string $message, string $sessionId): string { foreach ([openai, local] as $gateway) { try { return call_gateway($gateway, $message, $sessionId); } catch (GatewayThrottleException $e) { log_warning({$gateway} 触发限流或状态异常, $e-getMessage()); continue; } } throw new RuntimeException(所有模型网关均不可用); }这个函数本身不长放到ModelGateway里即可。你还可以再接一层把失败日志写入文件或 Redis后台看到某个服务商连续失败 5 次就发告警。相比在前端做重试服务端降级能让调用方感知不到切换。注意continue前建议短暂usleep(200000)等待 200 毫秒给前一个服务商留出释放连接的时间也避免在异常风暴下把第二个服务商也打爆。本文还有配套的精品资源点击获取
PHP源码搭建AI聊天网站：API接口设计与LNMP部署实践
简介这套源码是一套面向PHP开发者、AI应用爱好者及网站二次开发者的轻量级在线聊天系统核心程序压缩后仅23KB部署门槛低适合快速搭建或集成到现有项目。系统内置用户管理、一键添加与修改接口、在线AI多模型聊天、文转图、图转图等功能并附带5种不同模式的API接口源码方便需要对外提供AI能力的开发者直接对接。资源包共22个文件以17个PHP业务文件为主体配合3个TXT说明或配置文档、1个HTML前端演示页面以及1个ZIP示例包整体体积约42KB目录结构精简便于按需查阅。目前已有208人学习下载适合想低成本拥有AI聊天站点或研究轻量级接口方案的开发者。通过源码可掌握接口动态配置与多模型切换的核心思路附带的对接demo还能帮助快速理解从页面提交到AI模型返回的完整调用过程。1. 一套PHP源码包如何撑起AI在线聊天网站系统这类 PHP 网站系统解决的需求很直接给你一个带前端聊天气泡、后端会话管理和 API 接口调用的完整站点上传到服务器填上模型 API Key就能跑起一个 AI 聊天网站。很多团队要的不是从零写代码而是把一套现成源码快速变成客服、内网知识助手或私人对话服务。这套代码的关键不在聊天 UI 有多炫而在 PHP 如何把用户消息、会话历史和模型 API 接口编排起来。反直觉的一点是越成熟的源码包越会把模型接口藏在后端前端只拿到一个业务返回这样既避免密钥泄露也方便你切换模型供应商。我下面按源码包里最常遇到的实现方式从请求链路、配置文件、LNMP 部署到 API 接口的流式封装逐层拆开让拿到同类型 PHP 源码的人能直接上手改配置也能定位到具体文件去改逻辑。2. 拆解AI聊天网站系统的核心链路PHP会话与API接口编排2.1 聊天请求在PHP里的流转路径从Session到模型网关一个成熟的 AI 在线聊天网站前端不会直接拿模型 API 的地址和密钥去发请求而是把请求统一交给 PHP 后端。常见流转路径是这样的用户在输入框提交消息JavaScript 把消息和会话 ID 通过 POST 提交到/api/chat这样的控制器控制器先做参数校验和内容安全检查再读取当前会话的历史消息拼装成模型需要的messages结构随后把这次请求交给模型网关服务类网关负责向实际的大模型 API 发请求并处理超时、限流和响应解析最后把模型返回的内容写回数据库或 Redis同时追加为新的历史消息前端拿到结果后渲染到页面。这个链路里最容易忽略的是“历史会话”的读写位置。有些源码把历史存在数据库的conversation_messages表里有些存在 Swoole Table 或 Redis 里两者对性能的影响差别很大。你拿到源码后第一件事不是去看模型调用而是先找message相关的模型类确认会话上下文是从哪读的。实际排错中我发现很多“答非所问”的问题并不是模型参数问题而是上下文拼接时把角色顺序打乱了或者把系统提示词丢掉了。另外一个值得留意的点是 API 接口的幂等设计。聊天页面在弱网下会多次重试提交如果不做请求去重用户会看到模型回复两次数据库里也会留下重复记录。常规做法是在前端生成一个client_msg_id后端在固定时间窗口内对同一个 ID 只处理一次这个逻辑通常写在中件间层或控制器构造函数里。2.2 对接大模型API的最小PHP代码先跑通一个非流式对话不管源码包用的是原生 PHP 还是 ThinkPHP、Laravel底层要跑通一个模型对话最可靠的方式就是封装一个类通过 cURL 发起 HTTPS 请求。下面这段代码是 OpenAI 兼容接口的最小实现绝大多数服务商都支持这种格式?php /** * 最小模型 API 调用示例 * 对应源码包中 app/service/ModelGateway.php 的简化版本 */ function chat(string $message, string $sessionId): string { $apiKey YOUR_API_KEY; $url https://api.example.com/v1/chat/completions; // 从 Session 或缓存中取出该会话的历史没有则初始化 $messages load_history($sessionId); $messages[] [role user, content $message]; $payload [ model gpt-4o-mini, // 后台配置的模型标识可多套切换 messages $messages, // 角色包含 system/user/assistant temperature 0.7, // 0~2越高越发散 max_tokens 1024, // 单次回复的最大 token 数 stream false, // 先关闭流式跑通整体链路 ]; $ch curl_init($url); curl_setopt_array($ch, [ CURLOPT_POST true, CURLOPT_POSTFIELDS json_encode($payload, JSON_UNESCAPED_UNICODE), CURLOPT_HTTPHEADER [ Content-Type: application/json, Authorization: Bearer . $apiKey, ], CURLOPT_RETURNTRANSFER true, CURLOPT_CONNECTTIMEOUT 10, CURLOPT_TIMEOUT 120, CURLOPT_SSL_VERIFYPEER true, ]); $response curl_exec($ch); if (curl_errno($ch)) { throw new RuntimeException(API 请求失败: . curl_error($ch)); } $httpCode curl_getinfo($ch, CURLINFO_HTTP_CODE); curl_close($ch); if ($httpCode ! 200) { throw new RuntimeException(API 返回 HTTP {$httpCode}: . $response); } $data json_decode($response, true); $reply $data[choices][0][message][content] ?? ; // 将用户消息和助手回复一起写回历史供下一轮使用 save_history($sessionId, $messages, $reply); return $reply; }这段代码把三件事压在一个函数里构造messages数组、发起 HTTP 请求、保存上下文。CURLOPT_SSL_VERIFYPEER一定要保持为true有些源码为了本地调试把它关掉生产环境容易招致中间人攻击。CURLOPT_CONNECTTIMEOUT建议设 10 秒防止模型服务端 IP 不通时整个 PHP 进程长时间挂住。CURLOPT_TIMEOUT设为 120 秒是因为某些长文本模型处理时间会超过 60 秒但你如果把stream打开这个值要重新考虑因为流式连接是持续占用超时判断要按空闲时间而不是总时长。2.3 必调参数与鉴权方式temperature、max_tokens和stream不同聊天源码对参数的暴露程度不一样有的后台只放三个选项有的给你完整的模型参数面板。下面这张表是几个直接影响回复质量和成本的参数也是你拿到源码后最需要确认是否对上位的配置项。参数作用范围典型值调整逻辑temperature影响随机性0.3 ~ 0.9客服和代码场景调低创意写作调高top_p影响候选词集合0.8 ~ 1.0和 temperature 不要同时猛调会让输出极端max_tokens限制单次回复长度512 ~ 2048后台往往用“最大回复字数”字段控制的是它presence_penalty鼓励引入新话题0.0 ~ 0.6多轮长时间对话里调高可减少重复词frequency_penalty惩罚高频词汇0.0 ~ 0.6和 presence 一起调能改善“嗯”“好的”这类词stream是否流式返回false / true聊天网站必须 true非流式只用于接口调试鉴权部分我见过最稳妥的做法是服务端持有主 Key然后在 PHP 里生成一个短期 token 给前端。前端请求/api/chat时带上这个 token后端先解析出user_id和session_id再结合当前用户是否允许调用该模型做二次判定。有些源码简化成前端无条件传一个api_key参数这种做法只适合本机 demo一旦暴露到公网别人可以直接盗刷你的模型额度。拿到源码后请优先搜索api_key出现在哪些文件里如果出现在public/static/js下这个包需要做权限改造。常见安全改法是所有模型请求统一走后端前端只传递消息内容和服务端下发的会话标识。在鉴权之外还需要关心 API 接口的返回结构。一些国内服务商虽然兼容 OpenAI 格式但错误返回体里的字段是自定义的比如error.response.message而不是error.message。你改配置后如果一直报“解析错误”先拉起接口文档对比choices这块的层级。为了减少这种差异网关层通常可以做一次统一封装把不同服务商的响应转换成项目内部标准结构再抛给上层控制器。3. 源码包目录分工与关键配置项找对入口再改代码3.1 一份典型的PHP源码目录结构长什么样拆开.zip后你应当先用文件管理器看顶层结构而不急着传到服务器。常见的 AI 聊天 PHP 源码即便框架不同目录设计也往往遵循“入口、应用、配置、外部库”的划分方式。下面是一份较典型的结构命名可能略有出入但角色一致. ├── app │ ├── controller │ │ ├── Chat.php # 聊天主控制器 │ │ ├── Auth.php # 登录/鉴权 │ │ └── Admin.php # 后台管理 │ ├── service │ │ ├── ModelGateway.php # 模型网关负责调 API 接口 │ │ └── SessionService.php # 会话管理 │ ├── middleware │ │ └── ContentCheck.php # 内容安全中间件 │ └── model │ ├── Conversation.php │ └── Message.php ├── config │ ├── app.php # 应用基础配置 │ ├── database.php # 数据库连接 │ ├── model.php # 模型服务商配置 │ └── session.php # 会话驱动配置 ├── public │ ├── index.php # 单入口文件 │ ├── static │ │ ├── js/chat.js │ │ └── css/style.css │ └── uploads # 用户上传文件目录 ├── runtime │ ├── logs │ ├── cache │ └── session ├── vendor # Composer 依赖 └── install ├── install.php # Web 安装引导 └── sql └── install.sql这个结构里有几个点需要你特别留意。public是 Web 根目录Nginx 必须在配置里把root指向它如果把 root 指到项目根目录别人就能直接下载config或.env文件。runtime目录必须允许 PHP-FPM 写否则日志和 session 写不进去系统会表现成一直登录失败。install目录在部署完成后要直接删除或改名否则有被重装覆盖数据库的风险。3.2 config配置文件里最值得改的字段不要一上来就改业务代码配置项才是你真正要动的部分。不同源码的配置文件名可能不同但字段含义大同小异。我整理了一份高频字段对照按优先级排列字段配置含义取值建议改错后果API_KEY模型服务商提供的密钥放在服务端不要提交到前端盗刷、额度耗尽API_BASE_URL模型接口的域名前缀以官方文档为准注意末尾不能多/v1接口 404DEFAULT_MODEL默认模型标识例如gpt-4o-mini或qwen-plus页面报模型不存在MODEL_LIST前端可选模型下拉列表与控制台实际开通的模型对齐选择后调用失败STREAM_OUTPUT是否开启流式输出聊天一般设为true用户看到一句话整体卡住MAX_HISTORY携带的历史消息条数10 ~ 20 条上下文太长费用和耗时上升SESSION_DRIVER会话存储方式file/redis/database多机部署时应使用 redisCONVERSATION_LIMIT每个用户会话数量上限100 ~ 500数据库无限膨胀REQUEST_RATE_LIMIT分钟级请求限制页面访问 30API 请求 60刷接口导致成本不可控API_BASE_URL是最容易出问题的一项。有些源码内部用rtrim($baseUrl, /) . /chat/completions拼接地址你在后台多写了一个/v1最终就会变成https://api.example.com/v1/v1/chat/completions。我建议在配置加载完成后用var_dump(trim(...))直接打出最终构造出来的 URL别靠猜。MAX_HISTORY决定一次请求携带多少轮上下文。数值太大token 成本会成倍增长数值太小多轮对话容易失忆。常规做法是取最近 8 到 15 条消息并且限制单条消息不超过 2000 字。好的源码会把超长历史做自动裁剪而不是直接截断因为硬切可能会切掉半句话。3.3 多模型切换与API接口路由的常见实现这类源码还有一个卖点后台可以切换多家模型服务商。实现方式通常不是写死每个请求的 URL而是维护一个网关配置在配置里注册多个服务商然后按当前站点设置的“默认服务商”去发请求。下面是一个常见的配置结构?php // config/model.php return [ default openai, // 当前启用哪个服务商 gateways [ openai [ api_key getenv(OPENAI_API_KEY), base_url https://api.example.com/v1, models [gpt-4o-mini, gpt-4o], ], local [ api_key getenv(LOCAL_API_KEY), base_url http://127.0.0.1:8000/v1, models [qwen2.5:7b], ], ], ];网关服务类里会先读取这份配置再根据外部传来的model参数决定去向。没有配置过的模型直接返回“模型不存在”而不是把请求发给默认服务商。这样做的真正好处是隔离异常某个服务商限流或调整接口后你只需要在default字段换一个值全站入口就切换走了。我一般会在测试环境里同时配两个服务商用一个“低成本模型”做冒烟测试确认配置类别和权限都没问题再切到正式模型。这样可以避免在做界面联调时消耗正式模型额度。如果你在源码里看到temp_model这种命名那通常是给管理员用的测试槽位和线上聊天主通道分开的不要混淆。4. 在LNMP上把AI网站系统跑起来环境、权限与排错4.1 环境准备PHP要求、扩展和伪静态规则这类 PHP 源码包一般在README.md或install目录里标注了最低 PHP 版本。目前较新的版本要求 8.1 或 8.2因为代码里会用到enum、readonly等新语法。如果服务器还是 PHP 7.4很多包会直接白屏或报语法错误。需要关注的扩展至少包括curl、openssl、json、mbstring、pdo_mysql、redis配合 Redis 会话驱动时。你可以在服务器上执行下面命令快速检查php -v php -m | grep -E curl|openssl|mbstring|pdo_mysql|redis缺扩展时用apt install php8.1-curl这类命令补装即可。但要注意不同 Linux 发行版的 PHP 包名不一样先确认自己的 PHP 版本再搜对应扩展包。Nginx 伪静态规则是部署的第二道关。多数源码使用单入口模式所有请求都进入public/index.php。下面是一份可以直接用的 Nginx 配置server { listen 80; server_name chat.example.com; root /data/www/ai-chat/public; index index.php index.html; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { fastcgi_pass unix:/run/php/php8.1-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~* \.(js|css|png|jpg|svg|woff2)$ { expires 7d; access_log off; } }try_files这一行的意思是如果磁盘上存在同名静态文件直接返回如果不存在就把请求交给index.php处理同时保留原始查询参数。这套规则对原生 PHP 和 ThinkPHP 都通用。root指向public目录而不是项目根目录这一步能挡住大量目录遍历风险。如果你发现后台路由一直 404第一件事就是看 Nginx 里是不是少了try_files或者遭遇了location /与location ~ \.php$的匹配冲突。4.2 部署步骤从上传源码到写入后台配置部署过程比写代码简单但每一步都可能拦你一下。我习惯按下面顺序操作每完成一步就做一次验证不要全部做完再查问题。# 1. 上传源码到目标目录且必须在项目根目录安装依赖 cd /data/www/ai-chat composer install --no-dev --optimize-autoloader # 2. 创建 .env 或 config.local.php从示例文件复制 cp .env.example .env vim .env # 3. 给运行目录写权限PHP-FPM 才能写日志和 session chmod -R 775 runtime uploads chown -R www-data:www-data /data/www/ai-chat # 4. 如果包带数据库迁移脚本则执行安装页或命令行迁移 php think migratecomposer install的作用是拉取vendor目录里的第三方依赖。很多从 Windows 上下载再打包进 zip 的源码会在压缩包里带上vendor但缺少一些 Linux 扩展对应的库。此时直接删掉vendor重新执行composer install更可靠。.env文件一定不要提交到版本库部署完成后可以用chmod 600 .env收紧权限。安装数据库时常见的是浏览器访问http://你的域名/install/install.php按引导填数据库名、用户名和密码。这一步要注意字符集选择务必选utf8mb4否则 Emoji 和中文人名会存成乱码。安装完成后立即删除install目录。有些源码的安装页在文件末尾会提示你“安装完成”但不会自动删除留给你的风险只能自己处理。4.3 高频故障排查白屏、500、空响应和超时实际跑起来后问题集中在下面几类。我把现象、常见原因和排查手段列成一张表方便你对着处理故障现象常见原因排查命令 / 方法访问首页直接白屏PHP 语法错误或缺少扩展php -l public/index.php看runtime/logs打开页面报 500目录权限或伪静态错误检查 Nginx error.logtail -f /var/log/nginx/error.log提交消息后一直“正在输入”流式响应被输出缓冲拦截在接口里输出前调用ob_end_clean()模型回复内容为空响应解析层级写错打印$data[choices][0]的原始 JSON请求模型接口超时服务器到服务商网络慢或 DNS 问题curl -I https://api.example.com看耗时API 报 401 / 403API Key 配置错误或权限不足核对.env中 Key 是否有多余空格后台登录成功但前端一直跳回登录页Session 目录不可写ps aux排查白屏时先开 PHP 错误显示在.env里临时把APP_DEBUG设为true或者直接修改php.ini里的display_errors On。上线前再把这些关掉否则日志会把数据库密码打出来。SSE 空响应是聊天场景里最讨厌的问题。即使接口代码正确Nginx 也可能对响应做缓冲导致前端迟迟收不到第一段文本。解决办法是第 5 章要讲的流式输出技巧同时在 Nginx 配置里为带X-Accel-Buffering: no的接口去掉代理缓冲。排查超时问题多留意 PHP-FPM 的request_terminate_timeout默认 30 秒对一些长文本模型根本不够用要改成 0 或在fastcgi.conf里单独给聊天接口设置更大的值。5. 进阶把AI网站系统的API接口封装成可复用的模型网关5.1 用PHP输出SSE流式响应聊天体验更接近官方客户端聊天网站如果每次都要等模型生成完再返回体验非常差。源码包到后期通常会支持 SSE 流式输出也就是服务端一边接收模型返回一边把数据块推送给浏览器。实现核心在于两点发出text/event-stream头以及禁掉中间层缓冲。下面是最小可用的流式发送封装?php function streamChat(string $message, string $sessionId): void { header(Content-Type: text/event-stream; charsetutf-8); header(Cache-Control: no-cache); header(X-Accel-Buffering: no); // 组装模型请求stream 固定为 true $payload build_payload($message, $sessionId); $ch curl_init($apiUrl); curl_setopt_array($ch, [ CURLOPT_POST true, CURLOPT_POSTFIELDS json_encode($payload), CURLOPT_HTTPHEADER [ Content-Type: application/json, Authorization: Bearer . $apiKey, ], CURLOPT_WRITEFUNCTION function ($ch, $chunk) { echo $chunk; ob_flush(); flush(); return strlen($chunk); }, ]); curl_exec($ch); curl_close($ch); }CURLOPT_WRITEFUNCTION会在每次收到数据块时被调用直接把原始 SSE 帧转发给浏览器。ob_flush和flush的作用是绕过 PHP 自身的输出缓冲让数据尽快到 Nginx。X-Accel-Buffering: no是告诉 Nginx 不要吞掉小块响应否则前端也要等攒够一定字节才触发onmessage。这条代码里的关键参数是build_payload必须设置stream true否则模型接口会把整段 JSON 一次性返回流式前端反而解析失败。5.2 给API接口加一层校验非法请求拦截在网关之前暴露在公网的聊天接口最怕被其他站点盗用或刷量。只靠前端按钮肯定不够我建议在网关入口处统一做三层校验请求频率、会话归属、内容安全。频率限制可以用 PHP 内置的session记录时间戳也可以用 Redis 的INCREXPIRE后者对集群部署更友好。# 校验你的接口是否按预期返回 429 限流响应 curl -i -s -X POST https://chat.example.com/api/chat \ -H Content-Type: application/json \ -H X-Session-Token: your-token \ -d {message:hello} \ -w \n耗时: %{time_total}s\n关注响应头里的HTTP/1.1 200和Content-Type就能判断 Nginx 和 PHP 链路是否正常。加上-i能看到原始头确认X-Accel-Buffering是否生效。接口验证时可以把max_tokens调到 10用最便宜的模型试通这样既不拖慢调试也不浪费额度。5.3 收尾技巧用联合接口实现模型故障自动降级如果你不只做演示还希望聊天接口的可用性更高我推荐一个轻量技巧在网关层写一个“故障降级”循环。当默认服务商返回 429、5xx 或连续超时自动把请求切到第二个服务商而不是直接告诉用户“模型服务不可用”。实现思路很简单把各个服务商封装成同一个接口用循环把可用项依次尝试一遍。?php function chatWithFallback(string $message, string $sessionId): string { foreach ([openai, local] as $gateway) { try { return call_gateway($gateway, $message, $sessionId); } catch (GatewayThrottleException $e) { log_warning({$gateway} 触发限流或状态异常, $e-getMessage()); continue; } } throw new RuntimeException(所有模型网关均不可用); }这个函数本身不长放到ModelGateway里即可。你还可以再接一层把失败日志写入文件或 Redis后台看到某个服务商连续失败 5 次就发告警。相比在前端做重试服务端降级能让调用方感知不到切换。注意continue前建议短暂usleep(200000)等待 200 毫秒给前一个服务商留出释放连接的时间也避免在异常风暴下把第二个服务商也打爆。本文还有配套的精品资源点击获取
