企业官网建设流程全解析

做学生成绩管理系统之前，我也以为这事很简单：无非是期末考试成绩录进系统，按权重算个总分，再排个名。真被教务处的老师拉去聊需求才发现，他们要的“综合评价”跟我想的完全不是一回事——平时作业、课堂表现、项目答辩、竞赛加分、甚至一票否决项都要进总分，而且不同课程权重还不一样，以前这些全躺在老师的Excel表里，各存一版，期末汇总时错漏百出。

我最后落地的方案，是同时用了ThinkPHP和Laravel两套PHP框架：一套管后台录入和权限，一套管计算和API输出，共享同一个MySQL库。这两个框架放在同一个项目里各干各的活，听上去有点折腾，但实际用下来边界特别清晰。这篇文章我就把这个方案的来龙去脉、数据模型、计算逻辑、以及部署时踩过的坑完整写出来，给刚好要做类似成绩系统的人一个参考，尤其是想整合多个PHP框架的同学，应该能省不少弯路。

1. 先想清楚“综合成绩”到底怎么算：评价维度的拆解

1.1 传统成绩方案的毛病

如果只是“期末考试成绩×60% + 平时成绩×40%”，那确实不需要什么系统。但现实是，老师手里的过程性数据特别多：签到率、课堂提问、小组作业、实验报告、期中测试，还有各类竞赛获奖加分。这些数据放Excel里，第一个问题是版本管理混乱，第二个问题是公式各有各的写法，第三个问题是最后汇总时没人说得清某个分数是怎么来的。

我这次的需求方明确提了一个指标：每个学生的最终综合分，必须能追溯到每个维度的原始得分和权重。也就是说，系统里不存“综合分=88.5”这种最终结果就完事，而是要存“考试成绩90分、平时作业85分、课堂表现80分、竞赛加分5分，按权重算出来88.5分”。这条要求直接决定了后面的表结构设计。

1.2 综合评价维度的最终划分

跟教务处反复讨论后，我们把所有可量化的评价维度收敛成了四类：

• 学业成绩类：期末考试、期中考试、平时测验、作业质量
• 过程表现类：出勤情况、课堂互动、实验实践、小组协作
• 奖励加分项：学科竞赛、论文发表、证书获取、志愿服务
• 否决性指标：考勤红线、学术诚信问题、考试违纪

否决性指标比较特殊，它不参与“加权重”算法，而是直接判定等级上限。比如学生一旦有学术不端记录，无论总分多高，综合等级最高只能到C。这块逻辑一开始没设计进去，后来补上时改了不少代码，所以我建议从一开始就在需求里把这类规则点出来。

1.3 不同课程类型权重配置

权重不能写死在代码里，这是我做这类系统最深的体会。不同院系、不同课程，评价侧重完全不同：思政课重平时表现，实操课重项目和实验，理论课重期末考试。

我最终用的是数据库配置权重组的方式，大致这样：

每组权重存成一条配置记录，对应到课程分组。权重总和也不是强制100%，引擎那里会做归一化处理，这个后面讲到具体计算时细说。

1.4 百分制到等级制的换算

综合分是百分制，但学院最终公示时用的是五级制（优秀、良好、中等、及格、不及格），成绩单上还要带学分绩点。换算规则也要可配置，我用的标准是：

• 90-100分：优秀，绩点4.0
• 80-89分：良好，绩点3.0
• 70-79分：中等，绩点2.0
• 60-69分：及格，绩点1.0
• 0-59分：不及格，绩点0

这条规则放在了数据库参数表里，而不是写死在代码中。后来有学院要求优秀率控制在20%以内，他们只要调参数就行，不用动代码。

2. 为什么一个项目里同时用ThinkPHP和Laravel

2.1 项目背景：既有遗留系统

需求方已有的教务管理后台是用ThinkPHP 5.1写的，跑了好几年，稳定。但这次的综合评价模块，计算逻辑复杂，还要对接学生端的查询API，直接在老代码上堆功能也可以，但想想以后要加队列、加缓存、加单元测试，Laravel的生态明显更合适。

所以我的方案不是“抛弃ThinkPHP重写”，也不是“只用Laravel替换”，而是让两个框架在同一套系统里共存：ThinkPHP保留已有的管理后台能力，Laravel承载新模块的计算和API。

2.2 框架分工

两个框架部署在同一台服务器、同一个域名下的两个子目录，共享同一个MySQL数据库。因为各自入口不同，路由不会冲突。

2.3 为什么这样分：三个实际理由

第一，团队上手成本低。老团队闭着眼睛能写ThinkPHP，让他们学新框架还要时间。ThinkPHP这边照常维护老功能，新模块的复杂逻辑交给Laravel，两边没有互相绑架的感觉。

第二，计算和API放Laravel侧更顺手。综合评价计算要写服务类、要做单元测试、要有队列异步处理，Laravel的Artisan命令行、Eloquent模型、Queue系统都是现成的。计算引擎跑在CLI环境里，比Web环境更稳定。

第三，边界清晰以后好逐步演进。如果哪天老后台某个模块也该升级了，可以一层层往Laravel迁移，而不是推倒重来。这套结构跑了大半年，我自己最直观的感受是：改ThinkPHP代码时不用担心碰坏计算逻辑，改Laravel代码时不用担心把后台界面搞崩。

2.4 两个框架之间的接口约定

两个框架不能用同一个session，所以它们之间完全不共享Web会话，而是通过一个简单的内部API交换数据：

• Laravel侧提供/internal/api/score/aggregate接口，接收student_ids、course_id、term参数
• ThinkPHP侧在审核发布时调用这个接口，触发某个班级某门课的综合分计算
• 请求头带上内部token，双方约定统一返回结构：code、message、data

这个接口不对外网暴露，只监听内网地址。如果两个框架不在同一台机器上，就用内网IP加token调用。

2.5 为什么不直接上微服务

有人可能会问：两个框架都放一起了，为什么不直接搞微服务？说实话，这个体量完全够不到微服务的层次，一共就一个学校几千名学生。微服务带来的服务发现、链路追踪、分布式事务，对这个项目是纯粹的负担。两个框架共享一个MySQL，计算结果统一写库，事务边界简单，出了问题也好排查。

3. 数据模型：可配置规则的表结构

3.1 明细行优先，拒绝宽表

一开始我也想过用宽表，“一个学生一行，二十个字段分别是各种成绩”，但很快放弃了。因为评价维度会调整，宽表加一个字段就是一次表结构变更。改成明细行之后，加维度不需要改表结构，只是多插几行数据，灵活得多。

核心表设计成四张：

• 成绩明细表：保存每个学生每个课程每个维度的原始得分
• 维度参数表：定义有哪些维度、默认权重、分值范围
• 权重分组表：不同课程类型对应的权重配置
• 综合结果表：保存计算后的总分、等级、排名

3.2 成绩明细表结构

CREATE TABLE `score_detail` ( `id` BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `student_id` INT UNSIGNED NOT NULL COMMENT '学生ID', `course_id` INT UNSIGNED NOT NULL COMMENT '课程ID', `academic_year` VARCHAR(20) NOT NULL COMMENT '学年，如2024-2025', `term` TINYINT NOT NULL COMMENT '学期：1或2', `dimension_code` VARCHAR(30) NOT NULL COMMENT '维度代码，如exam_score', `raw_score` DECIMAL(5,2) NOT NULL COMMENT '原始得分', `weight` DECIMAL(5,2) NULL COMMENT '本记录权重，可覆盖默认权重', `score_source` TINYINT NOT NULL DEFAULT 1 COMMENT '来源：1手动录入 2Excel导入 3系统计算', `operator_id` INT UNSIGNED NOT NULL COMMENT '操作人ID', `remark` VARCHAR(255) DEFAULT NULL COMMENT '备注，如补考/缓考/竞赛加分', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY `idx_student_course` (`student_id`, `course_id`), KEY `idx_course_term` (`course_id`, `term`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生成绩明细表';

这里有一个容易被忽略的点：weight字段允许为空，为空时走权重分组表里配置的默认权重。这样好处是支持“某次考试成绩权重调整”的特殊情况，不用新增一张覆盖表。但坏处是业务逻辑里要多判断一次，后面计算引擎会做统一处理。

3.3 维度参数表和权重分组表

CREATE TABLE `score_dimension` ( `dimension_code` VARCHAR(30) PRIMARY KEY, `dimension_name` VARCHAR(50) NOT NULL, `default_weight` DECIMAL(5,2) NOT NULL DEFAULT 0, `min_score` DECIMAL(5,2) NOT NULL DEFAULT 0, `max_score` DECIMAL(5,2) NOT NULL DEFAULT 100, `is_deductible` TINYINT NOT NULL DEFAULT 1 COMMENT '是否为扣分项', `sort_order` INT NOT NULL DEFAULT 0 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='评价维度参数表'; CREATE TABLE `score_weight_group` ( `id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `group_name` VARCHAR(50) NOT NULL COMMENT '权重组名', `course_type` VARCHAR(30) NOT NULL COMMENT '课程类型编码', `dimension_code` VARCHAR(30) NOT NULL, `weight` DECIMAL(5,2) NOT NULL, `valid_from` DATE NOT NULL COMMENT '生效日期', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_type_dim` (`course_type`, `dimension_code`, `valid_from`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='权重分组配置表';

权重配置加上valid_from日期，以后权重调整就是插入一条新配置，历史成绩依然按旧权重计算和回溯，不会因为参数改了导致往期成绩全部变化。这一点在我们上线后第二次调整权重时发挥了很大作用——有几个学院一直用历史数据核对排名，如果没有这个字段，根本说不清楚某学期为什么总分变了。

3.4 综合结果表：为什么存结果而不是实时算

有的同学觉得综合分实时算不就行了，省一张表。我解释一下为什么最终要落一张结果表：成绩发布后，学生端、教师端、打印成绩单、导出报表都在高频读取综合分。如果每查询一次就聚合一次，轻则SQL慢，重则计算逻辑在不同页面出现微妙不一致。

CREATE TABLE `score_result` ( `id` BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `student_id` INT UNSIGNED NOT NULL, `course_id` INT UNSIGNED NOT NULL, `academic_year` VARCHAR(20) NOT NULL, `term` TINYINT NOT NULL, `total_score` DECIMAL(5,2) NOT NULL COMMENT '综合分', `grade_level` VARCHAR(10) NOT NULL COMMENT '等级：优秀/良好/中等/及格/不及格', `credit_point` DECIMAL(3,1) NOT NULL COMMENT '绩点', `class_rank` INT DEFAULT NULL COMMENT '班级排名', `score_json` JSON NOT NULL COMMENT '各维度得分存档，用于追溯', `version` INT NOT NULL DEFAULT 1 COMMENT '版本号，每次重算+1', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1草稿 2已发布', `published_at` DATETIME NULL, `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY `uk_stu_course_term` (`student_id`, `course_id`, `academic_year`, `term`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='综合成绩结果表';

score_json字段很关键。它把计算时使用的各个维度得分、权重一并存下来，不管以后权重参数怎么改，这条结果都能完整追溯当时的依据，就是前面说的“每个分数都有来处”。

4. 计算引擎实现：权重归一化和状态流转

4.1 引擎为什么要放在Laravel侧

计算引擎我放在了Laravel侧，用Command注册，支持手动触发和定时任务触发。原因就一条：Laravel的Eloquent配合模型事件，做数据聚合时写起来比ThinkPHP模型更顺手，而且更容易单测。计算引擎不依赖UI，它只做一件事：读取明细表数据，按维度加权聚合，写入结果表。

4.2 核心计算公式

综合分的计算公式看着简单，但有几个细节必须处理：

1. 权重归一化：如果配置的权重总和不是100%，不直接报错，而是按比例缩放。比如某门课只配了考试60%和作业30%，总和90%，实际计算时考试、作业分别按66.67%和33.33%参与。
2. 加分项替换：竞赛加分这类奖励加分，在100分制里会导致总分超过100，需要设定加分上限，默认单科总分封顶100。
3. 否决项判定：存在一票否决记录时，总分不做特殊处理，但等级直接降级。

公式可以写成：

normalized_weight_i = config_weight_i / sum(config_weight_i) dimension_score_i = raw_score_i * normalized_weight_i total_score = min(100, sum(dimension_score_i) + bonus_score)

4.3 Laravel核心服务类

计算聚合我写成一个独立的ScoreCalculator服务类：

<?php namespace App\Services; use App\Models\ScoreDetail; use App\Models\ScoreResult; use App\Models\ScoreWeightGroup; use Illuminate\Support\Facades\DB; class ScoreCalculator { public function calculate(int $courseId, string $academicYear, int $term): void { $studentIds = ScoreDetail::where('course_id', $courseId) ->where('academic_year', $academicYear) ->where('term', $term) ->distinct() ->pluck('student_id'); foreach ($studentIds as $studentId) { $this->calculateForStudent($studentId, $courseId, $academicYear, $term); } } public function calculateForStudent(int $studentId, int $courseId, string $academicYear, int $term): array { $details = ScoreDetail::where('student_id', $studentId) ->where('course_id', $courseId) ->where('academic_year', $academicYear) ->where('term', $term) ->get(); // 取权重配置：优先明细表上的覆盖权重，否则取权重组配置 $weights = []; foreach ($details as $detail) { $weights[$detail->dimension_code] = $detail->weight ?? $this->getDefaultWeight($detail->dimension_code); } $weightSum = array_sum($weights); if ($weightSum <= 0) { throw new \RuntimeException('权重总和必须大于0'); } $totalScore = 0.0; $scoreJson = []; foreach ($details as $detail) { $normalizedWeight = $weights[$detail->dimension_code] / $weightSum; $itemScore = $detail->raw_score * $normalizedWeight; $totalScore += $itemScore; $scoreJson[$detail->dimension_code] = [ 'raw_score' => (float) $detail->raw_score, 'weight' => (float) $weights[$detail->dimension_code], 'normalized_weight' => round($normalizedWeight, 4), 'item_score' => round($itemScore, 2), ]; } // 加分项上限处理 $bonusScore = $this->calculateBonus($details); $totalScore = min(100, $totalScore + $bonusScore); // 一票否决判定 $hasVeto = $this->hasVetoRecord($studentId, $courseId, $academicYear, $term); $grade = $this->convertToGrade($totalScore, $hasVeto); $creditPoint = $this->gradeToCreditPoint($grade); // 写入结果表 ScoreResult::updateOrCreate( [ 'student_id' => $studentId, 'course_id' => $courseId, 'academic_year' => $academicYear, 'term' => $term, ], [ 'total_score' => round($totalScore, 2), 'grade_level' => $grade, 'credit_point' => $creditPoint, 'score_json' => $scoreJson, 'version' => DB::raw('version + 1'), ] ); return $scoreJson; } }

这段逻辑看着不长，但有两个地方我建议你特别注意。第一是DB::raw('version + 1')，每次重算都会递增版本，方便查问题。第二是把score_json完整存下来，就算有人事后修改了原始成绩，结果表里依然保留了计算当时的全部数据。

4.4 状态机：草稿、审核、锁定、发布

综合成绩不能教师录完就直接生效，那是给自己挖坑。我设计了一个状态流转流程：

1. 草稿态：教师录入或导入成绩，存score_detail表，结果表没有记录
2. 审核态：教务审核成绩明细，此时可以退回给教师修改
3. 锁定态：审核通过后先锁定明细，禁止修改
4. 发布态：触发计算引擎，写入结果表，学生端可见

这个状态不是只放在某个字段里，而是拆成了两个维度：score_detail表有audit_status字段，score_result表有status字段。发布以后发现某个分数确实录错了，不能直接在表里改，要走“重新开放→修改→重新审核→重算发布”的流程。这个机制让管理员权限边界非常清晰。

4.5 缺考、缓考、重修这些边界情况

真实业务里最考验系统的其实不是正常成绩，而是各种边界情况：

• 缺考/缓考：考试成绩维度存NULL。计算引擎遇到NULL时，该维度按0参与权重，但结果表里备注为“缺考”，等级上限设为及格。
• 重修覆盖：同一门课学生重修后，取最高一次成绩作为有效成绩，但要在结果表保留两次计算记录，方便审计。
• 权重总和不是100%：前面代码已经处理，按比例归一化。这是我调试时踩过的坑，有门课的权重表漏配了一项，算出来全班成绩低了一截，加了归一化处理以后，配置的问题至少不会导致结果彻底失真。

4.6 缓存与异步发布

成绩发布那个瞬间，整个年级几千学生几百门课一起触发计算，Web请求明显变慢。我的做法是：发布操作只往队列里推一个任务，Laravel队列处理聚合计算，完成后用事件通知教务老师。学生端查询走Redis缓存，发布后第一次查询回源数据库，之后直接读缓存。

这块如果你只是小范围用，几十个学生几百条记录，确实不需要队列。但我这个场景是全校性的，队列方案让发布操作从几十秒降到了几百毫秒响应，体验差别很大。

5. 教师录入和Excel批量导入的实现细节

5.1 ThinkPHP端的录入表单与事务

ThinkPHP这边主要做的是“把数据好看地收进来”。单个成绩录入页面，我用了常规的POST表单，控制器里做了三件事：

public function store() { $data = $this->request->post(); // 1. 验证 $validate = new ScoreValidate(); if (!$validate->check($data)) { return json(['code' => 1, 'msg' => $validate->getError()]); } // 2. 事务写入明细 Db::startTrans(); try { $scoreDetail = ScoreDetailModel::create([ 'student_id' => $data['student_id'], 'course_id' => $data['course_id'], 'academic_year' => $data['academic_year'], 'term' => $data['term'], 'dimension_code' => $data['dimension_code'], 'raw_score' => $data['raw_score'], 'score_source' => 1, 'operator_id' => session('admin_id'), ]); Db::commit(); return json(['code' => 0, 'msg' => '保存成功']); } catch (\Exception $e) { Db::rollback(); return json(['code' => 1, 'msg' => '保存失败：' . $e->getMessage()]); } }

为什么这里加事务？因为同一门课程多个维度的成绩可能一次性提交，如果一个维度写成功、另一个维度写失败，成绩明细就少了数据，计算综合分时权重会对不上。加上事务，要么全成功，要么全回滚。

5.2 Excel模板设计

单条录入只适合补充个别数据，期中期末大规模录成绩还是得靠Excel。我设计了一个固定模板：第一列学号，第二列课程编号，后面的列是各个维度代码，比如exam_score、homework_score、class_performance。模板第一行是维度名，第二行是维度代码，第三行起是数据。

模板这么设计是有原因的，老师的原始Excel五花八门，有的列叫“考试成绩”，有的叫“期末成绩”，还有直接写“总评”。系统无法猜测列名，所以我的方案是让教务先把自己的数据结构整理成标准模板，然后我在导入逻辑里做严格校验，不靠猜。

5.3 批量导入的校验链

批量导入我用的是phpoffice/phpspreadsheet库，ThinkPHP里直接Composer引入就行。导入逻辑分三段：

1. 读文件校验：后缀必须是模板允许的xlsx或xls，超过2MB直接拒绝
2. 逐行校验：学号在student表里是否存在、课程号是否存在、分数是否在维度允许范围内、维度代码是否在配置表里
3. 落库校验：同一学生同一课程同一维度不能有重复记录，有则更新，无则插入

逐行校验错误信息要具体到行号和列名，不能只给“数据有误”四个字。比如：

这个错误报告生成后，教师可以当场在Excel里改，再重新上传，不用一行行去后台改。

5.4 权限控制与操作留痕

权限分四层：教务处能配置权重、审核、重算成绩；学院管理员能管理本学院课程和教师；任课教师只能录自己教的课，且只能改草稿态数据；学生只有只读查询权限。

每次录入、修改、导入、重算、发布都要写操作日志。我用了最简单的方案：建一张score_operation_log表，记录操作人、操作类型、目标记录ID、操作前后快照。这里没有用什么很高级的审计中间件，但已经能回答“这分数谁改的、什么时候改的、改了什么都、为什么改”这四个问题。

5.5 成绩审核发布的人性化细节

审核界面要能让教务直观看到差异。我做了对比视图：左边是教师提交的原始分，右边是当前结果表的成绩，中间列出修改痕迹。审核人不需要来回切换页面就能判断是否退回。

退回到教师端时，系统自动生成一条待办提醒，教师登录后台就能看到哪些班级的成绩被打回了，原因是什么。这个小功能在沟通成本上省了非常多，原来教务跟老师之间靠微信群来回传话，现在全在系统里闭环。

6. 部署上线与安全加固：两个框架同存的那些坑

6.1 运行环境清单

这套系统的运行环境我用的是LNMP，PHP版本定在8.1。两个框架对PHP版本要求不一样，ThinkPHP 5.1本来PHP 7.x也没问题，但我统一升到8.1后基本能跑，唯一要注意的是得把框架版本升级到最新小版本，老版本在PHP 8下会有兼容问题。

6.2 目录规划与Nginx配置

我把两个框架放在两个子目录：

/var/www/html/ ├── tphp/ # ThinkPHP入口，访问地址 /admin └── laravel/ # Laravel入口，访问地址 /api

Nginx配置里，/admin走ThinkPHP的public目录，/api走Laravel的public目录：

server { listen 80; server_name score.example.com; # ThinkPHP后台 location /admin { alias /var/www/html/tphp/public; try_files $uri $uri/ /admin/index.php?s=$uri&$args; index index.php; } # Laravel API location /api { alias /var/www/html/laravel/public; try_files $uri $uri/ /api/index.php?$query_string; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $request_filename; include fastcgi_params; } }

Nginx配置有个坑要提醒：两个框架的location块如果都配置了try_files，Nginx解析$uri时如果不能正确取到文件路径，会让PHP直接跑在错误的SCRIPT_FILENAME上。我调了半天，最后确认是alias加try_files的配合问题，改成了上面的写法才稳定。

6.3 Session统一到Redis

两个框架最开始各自用各自的session驱动，然后问题就来了：用户在ThinkPHP后台登录，跳转到Laravel的查询页面又要求重新登录。由于Laravel侧只提供API，其实不需要同一套session，但浏览器端管理界面和API有交叉调用，统一最省事。

最终方案是两个框架的session驱动都配置为Redis，key前缀不同，但共享同一个Redis实例。这样至少不会出现“ThinkPHP写入的session Laravel读不到”的诡异现象。如果你也同时跑两套框架，这一步建议提前做，别等用户反馈才处理。

6.4 安全加固清单

这类系统涉及学生成绩，数据敏感，安全上不能只靠框架默认配置。我最后落实的清单如下：

• 参数过滤：所有输入框做白名单验证，学号必须是数字，分数必须匹配/^\d{1,3}(\.\d{1,2})?$/
• CSRF保护：ThinkPHP的表单开启token验证，Laravel API用middleware处理跨域预检
• SQL注入：两个框架都强制走模型和查询构造器，不拼原生SQL；查询构造器解决不了的地方用预处理
• 依赖安全：Composer定期跑composer audit，发现第三方包漏洞及时升级。框架版本要保持在官方支持的版本线，老版本暴露安全问题的风险会越来越高
• 敏感数据脱敏：列表页默认隐藏完整学号，只显示后四位；导出Excel要设置权限校验，下载链接带时效性token
• 操作日志：所有变更都记录日志，日志文件禁止写入Web根目录

6.5 我踩过的三个典型问题

第一个是CLI和FPM的环境差异。Laravel队列在CLI下跑，读取的.env和配置跟FPM不一样。我一开始没注意队列任务里用了相对路径，结果发布通知里的PDF生成路径在命令行下全错了。解决方法是所有路径一律用绝对路径，或者用base_path()这类框架封装的函数。

第二个是时区问题。PHP默认时区是UTC，中国用户看到的时间差了8小时。我统一在php.ini里设置了date.timezone = Asia/Shanghai，同时Laravel的config/app.php里的timezone也要改成Asia/Shanghai，两边对不上就会出现成绩发布时间错乱。

第三个是上传限制。Excel文件稍微大一点就上传失败，排查下来是Nginx的client_max_body_size默认只有1M。我把这个值调整到了20M，同时在ThinkPHP的upload配置里同步改了限制，两个地方都改了才生效。

最后再说两句经验

这套系统从需求调研到上线，前后大概花了两个月。如果让我重新做一次，最大的调整是：不要一上来就建那么多表、做那么复杂的审核流。先跑通最小闭环——教师录成绩、引擎算总分、学生查结果，这个链条通了之后，再一步步加权重配置、加审批、加导入导出，每加一个功能都验证一下不影响已有数据。我前期在宽表设计上犹豫了一周，最后推翻重来，这个教训挺深刻。

还有一个很实际的经验：成绩系统最重要的不是技术炫不炫，而是数据能不能追溯。任何一条综合分，你都要能点开看到它是怎么算出来的、每个维度原始分是多少、权重是谁配的、什么时候生效的。有了这个底子，后续不管领导要什么报表、什么排名分析，都不用慌。

如果你也要做类似的学生综合评价系统，或者正纠结ThinkPHP和Laravel该选哪个，我的看法是：不必选。老系统是ThinkPHP就继续用它处理熟练的增删改查，新模块需要复杂计算和API就用Laravel，中间用一张共享数据库和简单的内部接口对接，完全可行。关键是边界划清楚，别让两个框架互相渗透，维护起来就没那么可怕。