内容摘要：去年帮朋友处理一个二手交易平台的订单模块，数据库里翻出一堆状态混乱的支付记录。那个项目用的就是ThinkPHP 5.1，代码写得随意，但商城核心逻辑跑得还算稳。这件事让我重新审视ThinkPHP在电商

去年帮朋友处理一个二手交易平台的订单模块，数据库里翻出一堆状态混乱的支付记录。那个项目用的就是ThinkPHP 5.1，代码写得随意，但商城核心逻辑跑得还算稳。这件事让我重新审视ThinkPHP在电商场景里的定位——它没那么时髦，可你要快速搭一个能用的App商城后端，它依然是很多中小团队的首选。

ThinkPHP做App商城，最直接的入口是路由和控制器。App端发来的请求通常不带什么花哨的RESTful规范，就是POST一个接口地址，参数塞在JSON里。TP的Route::post('/api/goods/list', 'api/Goods/list')这种写法，两分钟就能把接口挂上去。我见过一个日活三千左右的商城，商品列表、详情、下单、支付回调全走TP的控制器方法，每个方法平均不到四十行代码。控制器里直接调模型，模型里写查询构造器，没有Repository层，没有Service层，照样跑了一年多没出大故障。

数据库这块，TP的查询构造器对商城场景够用。商品表关联规格表、规格值表、库存表，用join和where拼一拼，写起来比手写SQL快。但有个坑：TP的where链式调用在复杂条件下容易生成冗余括号，尤其是多规格筛选的时候。我自己的习惯是，超过三个条件的查询直接写原生SQL，用Db::query()执行，反而更可控。缓存方面，TP内置了Redis和Memcached驱动，商品详情页的缓存key按goods_id加版本号来设计，更新商品时删掉旧key，这个套路在TP里实现起来很顺手。

支付回调是商城后端的命门。微信支付和支付宝的回调地址必须公网可访问，TP的Route::post('pay/notify/wechat')这种路由要记得关闭CSRF中间件，否则回调请求会被拦截。我见过有人在这上面栽跟头，调试了半天以为是签名问题，其实是TP的全局中间件把回调POST给挡了。回调里的验签逻辑建议单独抽一个类，别塞在控制器里，不然以后换支付渠道会改到崩溃。

App商城和网页商城有个区别：App端更依赖接口返回的JSON结构统一。TP默认返回的是HTML或者数组，需要自己封装一个ApiResponse工具类，统一code、msg、data三个字段。这件事看起来小，但接口一多，前端对接效率差很多。我习惯在TP的公共控制器里写一个_success()和_error()方法，所有API控制器继承它，省得每个方法都手写json_encode。

性能上，TP6比TP5提升明显，尤其是依赖注入和中间件管道。但很多老商城项目还在TP5.1上跑，因为升级成本高。如果新开项目，我建议直接上TP6，配合think-queue做订单超时关闭、库存回滚这些异步任务。队列用Redis驱动，一个订单创建后扔个延迟任务进去，二十分钟没支付就自动取消，比写定时脚本扫表优雅得多。

模板引擎这块，App商城其实用不上TP的View层。接口返回JSON，前端用Flutter或者UniApp渲染，TP只负责数据。但后台管理页面可以用TP的模板，省得再搭一套Node服务。我见过一个团队用TP6同时写API和后台，后台模板里直接调模型方法，虽然耦合，但开发速度确实快。

安全方面，TP的自动过滤机制能挡掉一部分XSS，但SQL注入还是得靠参数绑定。商城里的搜索框、商品评价这些用户输入的地方，千万别用字符串拼接。TP的where('name', 'like', '%'.$keyword.'%')这种写法，框架内部会处理转义，但如果你直接写where("name like '%$keyword%'")，那就是给自己挖坑。

最后说个实际观察：用TP做App商城的团队，往往不是技术驱动型，而是业务驱动型。他们需要的是两周内出一个能下单、能支付、能看订单的版本，而不是花一个月搭微服务。TP的文档中文友好，遇到问题百度一下就有答案，这对小团队来说比技术先进性重要得多。商城这种业务，稳定压倒一切，TP恰好能提供这种稳定。