📋 通俗版评估报告
🏗️ 目前架构
根据代码分析，目前架构是基于开源后台fastadmin+社区插件快速生成的，后又再改了一些插件实现不到的功能导致框架层(thinkphp)→开源面板层(fastadmin)→插件层(万联商城)→小曾(开发公司)层 任何一层出问题系统都会造成安全漏洞，更严重的是这些漏洞都是公开可查的，fastadmin官方有报出漏洞 社区插件水平参吃不齐,改动插件更是在不了解插件的情况下直接改的也会容易出问题(因为每个人编写习惯不一样外包公司不可能细致研究每个社区插件更不会按商业运营角度去做)，导致隐含着巨大的安全隐患，
而我们作为有金融属性的系统(我们系统要保管和调用别人的第三方钱包)，安全问题尤为重要
至于性能上 连最基本的数据库索引也没有，更不用说缓存和并发的优化问题
🚨 安全性能主要问题是
- 代码严重不规范 存在大量(平均每14个文件就有一个而且都是关键文件)直接可以用网页代码控制整台服务器的代码调用命令的权限(可能社区插件故意隐含的后门或者是外包公司编码不注意造成的)
- 作为金融系统却使用了大量SDK (SDK相当于官方演示代码所有开发者手上的代码是一样的)
- 数据泄露风险： 硬偏码(就是把密码写在的php文件中),没有脱敏(就是支付秘钥、接口通证等所有都是明文储存的)
- 数据被修改的风险 (虽有框架但却大量使用$_GET、$_POST等超全局变量)一不小心就会造成sql注入 跨站xss攻击等风险
- 架构层自带的问题： 代码世界没有完美但不能是公开的 否则受到无差别攻击只是时间问题
⚡ 性能方面：
假设安全问题可以存在一定侥幸心理 那么性能方面也可能是压垮项目的直接问题
我先合理设定了评估目标 500店铺 2万多sku 根据推算保守十多万的小程序会员 得出峰值（假设10-20%交易量集中在1-2小时）系统需要支持最高每秒100笔的涉及第三方的交易(这不是我们可以干预的第三方，所以只要一笔出错就会引发连锁效应)的合理性能目标，基于这个目标进行评测，得出结论是 相差太远
🔥 主要问题是
- 算法复杂度问题 (用大量嵌套逻辑累加造成的指数式循环递增问题有非常多约占16%)
- 数据库毫无索引 (相当于一本没有目录的字典，每找一个字都需要翻几百页)
- 毫无缓存 (把常用数据储存在内存中而不是每次都是数据库找)
- 大量重复计算 而且相关的代码重复复制粘贴无数次 导致没有办法集中修改 导致性能问题非常难解决
- 没有任何并发概念也没有任何队列操作，只能期望同一秒不要有两笔交易(好比100个学生一起问老师不同的问题 老师根本无法回答，而排队一个一个问就可以)
🔧 最后说说项目维护和优化难度
项目有7,469个PHP文件，但真正业务代码只有561个(不到8%)
维护难度：
- 各种依赖包：1,889个文件 (占25.3%)
- 真正业务代码：仅561个文件
典型的"垃圾堆积"项目 - 用一两个功能却引入整个SDK，是维护和优化的噩梦
⚠️ 重要声明
此刻我仅作为专业技术顾问的身份花了大量时间写下这份报告，不带有任何商业目的保证这份报告的专业和公正 此时若闭眼认可和验收第一期工作是对项目的极度不负责任的行为
报告出具日期: 2025年10月12日
评估对象: 便利店系统(第一期)
评估人: 东