简介这是一套基于ThinkPHP开发的后台答题类微信小程序完整源码面向PHP后端开发者与小程序全栈学习者解决在线题库管理、红包奖励发放、流量主收益对接等轻量级知识变现场景的快速落地问题。资源包为ZIP格式大小45.71MB包含前后端全部代码文件含数据库SQL脚本、ThinkPHP后台源码、小程序前端项目其中data目录提供初始化题库结构source目录为PHP后台核心小程序端涵盖app.js配置入口及流量主接口调用逻辑。已有494人学习下载适合中初级开发者通过实战掌握小程序PHP后台协同开发、微信流量主接入流程及后台CMS基础功能实现。读者可直接部署运行获得可上线的小程序原型支持题库增删改查、用户答题记录追踪、红包兑换配置及后台实时收益查看等功能所有配置项清晰标注关键路径如数据库连接、域名与AppID均已预留替换位置。1. 项目概述一个修复版的ThinkPHP后台答题小程序最近在整理过往项目时翻出了一个基于ThinkPHP的后台答题小程序源码。这个项目最初是几年前为了一个线上知识竞赛活动开发的当时为了赶进度前后端都留下了一些“技术债”比如接口响应慢、前端在某些机型上白屏、后台管理功能不完善等等。后来活动结束代码就搁置了。最近有朋友需要类似的功能我就把这个老项目翻了出来花了不少时间进行了一轮系统的修复和更新。现在的版本可以说是把当年踩过的坑都填平了前后端的体验都流畅了不少。这个项目麻雀虽小五脏俱全非常适合想学习ThinkPHP全栈开发或者需要快速搭建一个轻量级在线答题、考试、测评系统的朋友。它核心就是一个前后端混合架构后端采用经典的ThinkPHP 6.0框架负责用户管理、题库管理、试卷生成、答题记录、数据统计等所有业务逻辑和数据处理前端则是一个独立的微信小程序通过API与后端交互实现用户登录、答题、查看成绩等功能。这次修复的重点就是让这套“老搭档”配合得更默契运行得更稳定。如果你正想找一个带完整后台管理、开箱即用、并且代码结构清晰易于二次开发的答题小程序项目来学习或直接使用那么我这次整理修复的这套源码应该能给你提供一个不错的参考模板。接下来我就详细拆解一下这个项目的整体设计、修复的关键点以及具体的实现细节。2. 项目整体架构与核心设计思路2.1 技术栈选型与考量当初选择这个技术栈主要是基于“快速验证、稳定可靠、生态丰富”的原则。虽然现在更流行前后端完全分离如Spring Boot Vue/React但对于中小型、特别是需要快速上线的项目ThinkPHP全栈方案依然有它的优势。后端ThinkPHP 6.0为什么是ThinkPHP首先PHP的部署成本极低几乎任何虚拟主机都支持这对于项目初期的试错和推广非常友好。其次ThinkPHP框架在国内有着深厚的开发者基础文档齐全遇到问题容易找到解决方案。它的ORM模型、验证器、中间件等组件封装得比较友好能极大提升开发效率。选择6.0版本而非更老的5.1是为了更好地使用PSR规范、依赖注入等现代PHP特性让代码更规范。数据库MySQL。没什么好说的关系型数据库的标准选择与ThinkPHP的ORM配合天衣无缝事务处理、复杂查询都足够应对答题系统的需求。前端微信小程序为什么是小程序答题、测评这类轻量级应用用户使用门槛越低越好。微信小程序无需安装即用即走分享方便天然适合这种场景。它的框架学习曲线平缓且拥有微信的原生能力如登录、支付、订阅消息可以做出体验很好的应用。技术选型使用微信小程序原生框架开发没有引入Uni-App或Taro等多端框架。这是因为项目初期目标明确就是微信生态引入多端框架会增加复杂度。原生开发能获得最好的性能和最直接的官方支持。前后端通信RESTful API这是前后端交互的核心。我们设计了一套清晰的API接口规范所有请求都基于HTTPS使用JSON格式进行数据交换。例如/api/v1/question/list获取题目列表/api/v1/exam/submit提交试卷。身份认证采用JWTJSON Web Token。用户在小程序端登录后后端验证成功则生成一个Token返回给前端。前端后续的所有请求都在HTTP Header中携带这个Token。这种方式无状态非常适合API场景避免了服务器端Session存储的负担。这个架构看似传统但经过精心设计和修复后其开发效率、维护成本和性能表现达到了一个很好的平衡点特别适合个人开发者或小团队。2.2 核心功能模块拆解整个系统可以清晰地划分为两大模块小程序用户端和Web管理后台。小程序用户端核心功能流授权登录用户进入小程序调用微信wx.login获取code后端用code换取openid和session_key完成注册或登录并下发JWT Token。首页与活动展示可参与的答题活动、考试列表包括活动规则、时间、状态未开始/进行中/已结束。答题/考试界面试卷生成用户选择活动后后端根据规则如随机抽题、固定试卷动态生成一套题目包括单选题、多选题、判断题等。答题交互前端渲染题目用户选择答案。这里修复了一个关键点实时保存答题进度。不是等到最后一起提交而是每答一题或离开页面时自动将当前答案暂存到后端防止小程序崩溃或意外退出导致进度丢失。计时与交卷支持倒计时功能时间到自动交卷。用户也可主动提交。结果与排名提交后立即显示得分、正确答案解析。并提供排行榜按分数和用时进行排名。Web管理后台核心功能管理员登录独立的账号密码登录体系与小程序用户隔离。题库管理核心支持题目的增删改查可以按分类、难度、类型筛选。支持批量导入通过Excel/CSV模板这个功能在修复后变得非常稳定。活动/试卷管理创建答题活动设置活动名称、时间、规则如抽题数量、题目分类、及格线、可参与次数等。用户与数据统计查看所有参与用户列表。核心数据看板统计总参与人数、平均分、题目正确率排行榜、活动热度趋势图等。这是后台的价值所在能让运营者一目了然。系统设置配置一些全局参数如小程序AppID/Secret、首页公告等。这套功能模块构成了一个完整的闭环从后台配置活动到用户前端参与再到后台查看数据流程非常顺畅。3. 关键修复点与优化细节全解析原项目之所以需要修复主要是因为存在一些影响稳定性和用户体验的“暗病”。下面我挑几个最典型的修复案例详细说说问题和解决方案。3.1 修复一前端小程序“白屏”与渲染卡顿问题现象在某些安卓机型或网络稍差时小程序首页或答题页面加载缓慢甚至长时间白屏。根因分析图片资源过大且未优化原代码中活动海报、题目配图直接使用高清原图一张图好几MB在小程序网络请求和渲染时压力巨大。API请求串行且无加载状态进入页面后顺序请求用户信息、活动列表、公告等多个接口前一个不返回后一个就不发用户等待时间长且界面无反馈。WXML节点过多答题页面一次性渲染全部题目比如50道即便用了wx:for在低端机上滚动也会卡顿。修复方案与实操图片资源全面优化后台压缩在管理后台上传图片时使用ThinkPHP的图片处理库如intervention/image自动生成缩略图。例如列表页展示的图压缩至宽度750px质量70%。小程序端懒加载将页面内的所有图片标签image加上lazy-load属性。使用CDN可选如果图片非常多可以考虑将上传目录放到云存储如阿里云OSS、腾讯云COS并开启CDN加速后台只存储URL。// ThinkPHP后端示例生成缩略图 use think\Image; public function uploadImage() { $file request()-file(image); $savePath uploads/activity/; // 保存原图可选 $originalInfo $file-move(public_path() . $savePath); $originalPath $savePath . $originalInfo-getSaveName(); // 生成缩略图 $image Image::open($originalInfo); $thumbPath $savePath . thumb_ . $originalInfo-getFilename(); $image-thumb(750, 750)-save(public_path() . $thumbPath); // 将缩略图路径返回给前端使用 return json([url /. $thumbPath]); }API请求优化并行请求利用小程序Promise.all将不依赖的接口请求并行化。骨架屏与加载状态在数据返回前先渲染一个骨架屏Skeleton Screen让用户感知内容结构。每个按钮或区域在请求时显示loading状态。// 小程序端示例并行请求与骨架屏 Page({ data: { loading: true, userInfo: null, activityList: [] }, onLoad() { this.loadData(); }, async loadData() { // 显示骨架屏 this.setData({ loading: true }); try { // 并行请求用户信息和活动列表 const [userRes, activityRes] await Promise.all([ wx.request({ url: /api/user/info }), wx.request({ url: /api/activity/list }) ]); this.setData({ userInfo: userRes.data, activityList: activityRes.data, loading: false // 隐藏骨架屏 }); } catch (error) { // 错误处理 this.setData({ loading: false }); } } })列表分页与按需渲染分页加载活动列表、答题记录列表采用分页加载每次下拉刷新或触底加载更多。题目虚拟滚动针对超长试卷如果题目数量极多如超过100道可以考虑实现虚拟滚动只渲染可视区域内的题目。不过对于大多数考试30-50题一次性渲染并做好节点优化即可。优化手段包括简化WXML结构减少不必要的嵌套视图容器view使用纯文本节点text替代view包裹文本。修复心得前端性能问题很多时候不是代码逻辑错误而是细节处理不到位。图片、网络请求和渲染节点是三大性能杀手必须重点关照。优化后小程序的启动速度和页面流畅度有了质的提升。3.2 修复二后端API接口响应慢与超时问题现象提交试卷、查询排行榜等复杂操作时接口响应时间超过5秒甚至超时失败。根因分析N1查询问题这是原项目最大的痛点。例如查询一个活动详情连带其所有题目代码里先查询活动然后在循环中为每个活动ID去查询题目导致数据库查询次数爆炸式增长。复杂统计查询直接写在控制器像“计算用户平均分”、“题目正确率排行”这样的SQL直接写在控制器方法里又长又难以维护且没有利用索引。事务处理不当提交试卷时需要更新答题记录、更新用户分数、更新活动统计等多个表操作。原代码没有使用数据库事务一旦中间步骤出错会导致数据不一致如分数加了但记录没存上。JWT Token验证开销每次请求都在一个全局中间件里进行完整的JWT解码和数据库查询验证用户状态给简单接口如获取公告也带来了不必要的开销。修复方案与实操根治N1查询全面使用ThinkPHP模型的关联预加载功能。// 错误示例 (N1) $activities ActivityModel::select(); foreach($activities as $activity) { $questions QuestionModel::where(activity_id, $activity-id)-select(); $activity-questions $questions; } // 正确示例 (关联预加载) $activities ActivityModel::with([questions])-select(); // 在ActivityModel中定义关联 class ActivityModel extends Model { public function questions() { return $this-hasMany(QuestionModel::class, activity_id, id); } }这样ThinkPHP会通过一条或少量联合查询语句将所有关联数据取出性能提升数十倍不止。复杂查询迁移至模型层并优化将复杂的统计SQL封装到模型的自定义方法或模型作用域中。为频繁查询的字段如activity_id,user_id,created_at添加数据库索引。对于实时性要求不高的统计数据如历史总排名可以考虑使用定时任务缓存的方式。每小时计算一次并存入缓存前端请求时直接读取缓存。// 在模型里封装统计方法 class QuestionModel extends Model { // 获取某活动下题目正确率排行榜 public static function getCorrectRateRank($activityId, $limit 10) { return self::where(activity_id, $activityId) -field(id, content, (correct_count / (correct_count wrong_count)) * 100 as correct_rate) -where(correct_count wrong_count, , 10) // 只统计作答次数多的 -order(correct_rate desc) -limit($limit) -select(); } } // 在控制器中调用 $rank QuestionModel::getCorrectRateRank($activityId);引入数据库事务确保数据一致性// 提交试卷服务层方法 public function submitExam($userId, $activityId, $answers) { Db::startTrans(); try { // 1. 插入主答题记录 $recordId Db::name(exam_record)-insertGetId([...]); // 2. 批量插入答题详情 Db::name(exam_detail)-insertAll([...]); // 3. 更新用户总积分 Db::name(user)-where(id, $userId)-inc(score, $totalScore); // 4. 更新活动统计 Db::name(activity_stat)-where(activity_id, $activityId)-inc(participant_count); // 提交事务 Db::commit(); return $recordId; } catch (\Exception $e) { // 回滚事务 Db::rollback(); throw new \Exception(提交失败 . $e-getMessage()); } }优化JWT中间件将JWT解码这是一个纯计算操作很快和用户信息查询分离。在中间件中只做基础的Token解码和过期验证将解码出的用户ID存入请求对象。在后续的控制器或服务层中按需查询用户详细信息。对于很多只读接口可能只需要用户ID这样就避免了不必要的数据库查询。// 优化的JWT中间件 public function handle($request, \Closure $next) { $token $request-header(Authorization); if (!$token) { return json([code 401, msg Token缺失]); } try { $payload JwtUtil::decode($token); // 自定义JWT工具类解码 // 只验证基本信息和过期时间不查库 if ($payload-exp time()) { return json([code 401, msg Token已过期]); } // 将用户ID挂载到请求对象供后续使用 $request-userId $payload-uid; } catch (\Exception $e) { return json([code 401, msg Token无效]); } return $next($request); }修复心得后端性能优化数据库是主战场。80%的慢接口问题都出在SQL上。养成使用关联预加载的习惯、给关键字段加索引、善用事务是每个PHP后端开发者的基本功。另外分层设计很重要不要把逻辑都堆在控制器里合理使用模型、服务层代码会清晰好维护得多。3.3 修复三后台管理功能增强与体验优化原后台功能简陋更像是一个“数据录入器”缺乏运营和分析能力。修复与增强内容批量导入题库功能强化模板标准化提供下载清晰的Excel模板包含题目类型、题干、选项A/B/C/D、正确答案、解析、分类、难度等列并做好数据验证说明。导入过程可视化与容错上传Excel后后端使用PhpOffice\PhpSpreadsheet读取先进行预校验格式、必填项、答案合法性将错误信息如“第5行正确答案‘E’不存在”汇总返回给前端。全部校验通过后再执行批量插入并提示“成功导入XX条失败XX条”。异步导入可选对于上千条的大批量导入可以引入消息队列如Redis队列实现后台异步导入避免HTTP请求超时。数据可视化看板使用ECharts或AntV等前端图表库替换原来的纯数字展示。核心图表折线图展示每日参与人数趋势方便观察活动热度变化。饼图/柱状图展示题目分类占比、不同难度题目数量分布。排行榜表格展示题目正确率排行哪道题最难/最易、用户积分排行。后端提供聚合好的统计数据接口前端负责渲染。数据可以适当缓存减轻数据库压力。操作日志记录记录后台管理员的关键操作如“管理员[张三]于2023-10-27 15:30:22 删除了题目[ID: 123]”。实现方式创建一个AdminLog模型在相应的控制器方法如删除、修改中业务逻辑执行成功后写入一条日志记录。这对于追溯问题、安全审计非常有用。前端后台界面重构原后台使用简单的jQuery和Bootstrap交互生硬。我们将其重构为基于Vue.js 3 Element Plus的单页面应用SPA。这样做的好处是前后端分离更彻底交互体验更流畅无刷新跳转组件化开发使得代码复用性高新增功能模块更方便。修复心得一个产品的后台决定了它的运营上限。好的后台能让运营人员高效工作快速发现问题。可视化、批量操作、操作追溯是提升后台效率的三个关键点。将后台前端现代化Vue/React虽然增加了初期成本但对于长期维护和功能迭代是绝对值得的投资。4. 部署与运维指南项目修复好了最终要稳定地跑起来。这里分享一套经过验证的部署流程和运维注意事项。4.1 服务器环境准备推荐使用Linux服务器如CentOS 7/8或Ubuntu 20.04 LTS资源1核2G起步。安装基础软件# 更新系统 sudo yum update -y # CentOS # 或 sudo apt update sudo apt upgrade -y # Ubuntu # 安装PHP 7.4ThinkPHP 6.0要求 sudo yum install epel-release sudo yum install -y https://rpms.remirepo.net/enterprise/remi-release-7.rpm sudo yum install -y yum-utils sudo yum-config-manager --enable remi-php74 sudo yum install -y php php-fpm php-mysqlnd php-mbstring php-xml php-gd php-curl # 安装MySQL 5.7 或 MariaDB sudo yum install -y mariadb-server mariadb sudo systemctl start mariadb sudo systemctl enable mariadb # 安装Nginx sudo yum install -y nginx sudo systemctl start nginx sudo systemctl enable nginx # 安装Composer (PHP依赖管理) php -r copy(https://getcomposer.org/installer, composer-setup.php); php composer-setup.php php -r unlink(composer-setup.php); sudo mv composer.phar /usr/local/bin/composer配置PHP-FPM和Nginx主要调整php-fpm进程池/etc/php-fpm.d/www.conf中的pm进程管理方式对于小内存机器建议用ondemand或dynamic并设置合理的pm.max_children。Nginx配置关键点将根目录指向ThinkPHP项目的public目录并配置好try_files和fastcgi参数以支持ThinkPHP的PathInfo路由。# /etc/nginx/conf.d/your_domain.conf server { listen 80; server_name your_domain.com; # 或服务器IP root /var/www/quiz_system/public; # 指向public目录 index index.php index.html; location / { try_files $uri $uri/ /index.php$is_args$args; } location ~ \.php$ { fastcgi_pass unix:/run/php-fpm/www.sock; # 根据实际sock文件调整 fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } # 禁止访问敏感文件 location ~ /\.(env|git|svn) { deny all; } }配置MySQL数据库# 运行安全初始化脚本 sudo mysql_secure_installation # 登录MySQL创建数据库和用户 mysql -u root -p CREATE DATABASE quiz_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER quiz_userlocalhost IDENTIFIED BY YourStrongPassword123!; GRANT ALL PRIVILEGES ON quiz_db.* TO quiz_userlocalhost; FLUSH PRIVILEGES; EXIT;4.2 项目代码部署与初始化上传代码将修复后的项目代码除runtime、public/uploads等运行时目录上传到服务器例如/var/www/quiz_system。安装PHP依赖cd /var/www/quiz_system composer install --no-dev --optimize-autoloader # 生产环境跳过开发依赖环境配置复制.env.example文件为.env。编辑.env文件配置数据库连接、Redis连接如果用了缓存/队列、小程序AppID/Secret等。APP_DEBUG false DATABASE_HOSTNAME 127.0.0.1 DATABASE_DATABASE quiz_db DATABASE_USERNAME quiz_user DATABASE_PASSWORD YourStrongPassword123! # 小程序配置 WX_APPID your_appid WX_SECRET your_secret目录权限与存储链接# 设置运行时目录权限 chmod -R 755 /var/www/quiz_system chown -R nginx:nginx /var/www/quiz_system # 用户组根据实际运行Nginx的用户调整 # 确保runtime目录可写 chmod -R 777 /var/www/quiz_system/runtime # 如果使用了上传确保public/uploads目录可写 mkdir -p /var/www/quiz_system/public/uploads chmod -R 777 /var/www/quiz_system/public/uploads数据库迁移与数据填充如果使用了迁移# 在项目根目录执行ThinkPHP命令 php think migrate:run php think seed:run # 或者更常见的是直接导入SQL文件 mysql -u quiz_user -p quiz_db /path/to/your/database.sql4.3 小程序端部署修改配置在小程序开发者工具中打开项目修改app.js或配置文件中apiBaseUrl为你的后端服务器域名必须是HTTPS。上传与提交审核在开发者工具中点击“上传”填写版本信息。然后登录微信公众平台将上传的代码提交审核。审核通过后即可发布。服务器域名配置在微信公众平台后台的“开发管理”-“开发设置”-“服务器域名”中将你的后端API域名添加到request合法域名列表中。部署避坑指南HTTPS是必须的微信小程序要求所有网络请求必须使用HTTPS。你需要为你的服务器域名申请SSL证书可以使用Let‘s Encrypt免费证书并在Nginx中配置好。跨域问题如果后端API域名与小程序的request域名不一致需要在ThinkPHP后端配置中间件允许跨域。我们已经在修复版中内置了此中间件。定时任务如果使用了缓存统计、清理临时文件等定时任务需要使用Linux的crontab来执行ThinkPHP的命令行指令。# 例如每天凌晨2点清理过期缓存 crontab -e # 添加一行 0 2 * * * cd /var/www/quiz_system php think clear:cache日志与监控务必配置好ThinkPHP的日志runtime/log并定期查看。对于生产环境可以配置日志轮转避免单个文件过大。使用top、htop或nginx status监控服务器资源使用情况。5. 常见问题排查与实战技巧在实际开发和运维中总会遇到一些“诡异”的问题。这里我把修复和部署过程中遇到的典型问题及解决方法整理出来希望能帮你少走弯路。5.1 小程序端常见问题问题1wx.login获取的code在后端兑换openid时失败提示code been used或invalid code。原因微信的code具有一次性且极短的有效期约5分钟。常见原因有1网络延迟导致前端code发送到后端时已过期2后端处理太慢在兑换前code已过期3不小心重复发送了相同的code。解决前端优化在wx.login成功的回调里立即发起请求不要做其他同步耗时操作。后端重试机制谨慎后端收到兑换请求如果微信返回code been used错误可以尝试让前端重新执行一次wx.login获取新code。但更好的做法是优化后端兑换接口的性能确保快速响应。使用wx.checkSession在需要用到登录态的操作前先调用wx.checkSession检查session_key是否过期。如果过期则静默调用wx.login重新登录。问题2小程序在iOS和安卓上样式或表现不一致。原因微信小程序底层渲染引擎在不同系统上有差异以及CSS兼容性问题。解决多用Flex布局少用绝对定位Flex布局的兼容性最好。避免使用太新的CSS特性如gap属性在某些基础库版本中支持不好。真机多端测试务必在iOS和安卓的真机上进行测试模拟器无法完全还原所有问题。关注wx.getSystemInfo可以通过此API获取手机型号、系统版本、屏幕尺寸等用于特殊适配。问题3小程序包体积过大上传失败超过2M。原因图片、字体等静态资源过多。解决压缩图片使用工具如TinyPNG对所有图片进行压缩。移除无用资源清理未使用的图片和组件。使用网络图片将较大的、非核心的图片放到自己的服务器或云存储上小程序内通过image src”https://...”引用。分包加载如果项目复杂使用小程序的分包功能将不同功能模块拆分成子包按需加载。5.2 后端ThinkPHP常见问题问题1接口突然返回404但路由配置明明是对的。原因ThinkPHP的路由缓存在作祟。当你修改了路由文件route/app.php后如果没有清除路由缓存新规则可能不会生效。解决# 在项目根目录执行清除命令 php think clear:route # 或者更彻底地清除所有缓存 php think clear生产环境注意建议在部署脚本中加入清除缓存的命令。问题2使用Db::name(‘table’)-insert($data)插入数据$data里明明有字段却报错“字段不存在”。原因数据表字段名可能是驼峰如userName但ThinkPHP的Db类默认会将键名转换为蛇形命名user_name去匹配数据库字段。如果数据库字段就是驼峰就会对不上。解决统一命名规范强烈建议数据库表字段使用蛇形命名snake_case这是PHP社区的惯例。关闭字段自动转换在数据库配置中设置’fields_cache’ false并在模型里明确设置$name和$field属性但这种方法比较繁琐。使用模型Model替代Db类模型对字段名的处理更灵活也更符合ThinkPHP的ORM思想。问题3composer install时下载依赖特别慢或超时。原因默认的packagist.org源在国内访问速度不佳。解决更换为国内镜像源。# 全局配置推荐 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ # 或针对当前项目 composer config repo.packagist composer https://mirrors.aliyun.com/composer/ # 清除旧缓存 composer clear-cache问题4上传文件到public/uploads目录后通过URL无法访问。原因Nginx配置没有将该目录暴露为静态资源可访问。解决确保Nginx配置中对该目录做了正确的location处理或者更简单的在ThinkPHP的public目录下创建uploads软链接指向实际存储目录并确保Nginx对public目录有访问权限。我们修复版中已经处理了静态资源访问的问题。5.3 数据库与性能问题问题排行榜查询随着数据量增大越来越慢。分析排行榜查询往往涉及COUNT、SUM、ORDER BY和LIMIT在百万级数据上如果没索引会非常慢。解决加索引在exam_record表的activity_id、score、created_at字段上建立复合索引可以极大加速WHERE activity_id? ORDER BY score DESC, time_used ASC这类查询。分页查询不要一次性查询所有排名使用LIMIT offset, count进行分页。定时聚合对于“总积分榜”这类实时性要求不高的榜单可以每小时跑一次定时任务将计算结果存入一张rank_snapshot表前端查询时直接读这张快照表性能极佳。读写分离如果并发很高可以考虑MySQL主从复制将统计类查询指向从库。最后一点心得开发和维护这样一个项目日志是你的最好朋友。一定要把ThinkPHP的日志级别开到debug开发环境或info生产环境把关键的流程、SQL、错误信息都记录下来。当出现问题时第一时间去查runtime/log目录下的日志文件很多问题都能在这里找到线索。养成这个习惯能节省你大量的排查时间。本文还有配套的精品资源点击获取