欧欧淘严选编辑组发布时间：2026/10/15 16:12:06 来源：欧淘严选建站阅读：约5分钟

填好这张平台网站建设意见征求表，性能优化不拖一周

改个需求建站公司拖一周，这种憋屈事儿谁没遇到过？

上周刚上线的政务服务平台，甲方一句“把首页加载速度提上去”，开发组直接卡壳。不是技术不行，是需求根本没对齐，性能优化成了玄学。直到我们甩出那张《平台网站建设意见征求表》，把每个字都抠进代码里，首屏时间才从4.2秒压到1.8秒。

别把建站当玄学，把意见征求表当合同，把性能优化当工程。

项目背景：一张表治好了甲方的“反复横跳”

这是去年给某市人社局做的“社保查询平台”。甲方是信息中心的老张，技术背景扎实，但业务方（社保局）需求极碎。

痛点实录：

业务方说“要快”，但没说多快。是首屏1秒？还是API响应200ms？
业务方说“要稳”，但没说并发多少。是日均5000次访问？还是查养老金高峰期的3000QPS？
业务方说“要安全”，但没说是防SQL注入，还是防爬虫，还是过等保二级？

老张夹在中间，改需求像挤牙膏。我们介入后，第一步不是写代码，是填表。

这张《平台网站建设意见征求表》不是行政流程，是技术契约。它分四块：

模块	关键项	填写示例（错误 vs 正确）
性能基线	首屏时间	❌“要快” → ✅“P95首屏≤2s，LCP≤2.5s”
并发指标	峰值QPS	❌“要稳” → ✅“查养老金峰值3000QPS，错误率<0.1%”
安全合规	等保等级	❌“要安全” → ✅“等保二级，需过OWASP Top 10扫描”
浏览器兼容	最低版本	❌“都要支持” → ✅“Chrome 80+, Edge 80+, Safari 13+”

填完这张表，老张拿着去跟业务方对，业务方发现“要快”得加钱（CDN+缓存），就主动砍了30%的非核心功能。需求冻结了，性能优化才有了靶子。

技术选型：别迷信框架，先看“表”里的约束

很多人建站上来就问“用Vue还是React”，这是本末倒置。技术选型必须被《平台网站建设意见征求表》里的指标反推。

案例中的选型逻辑：

前端框架：Vue 3 + Vite
- 为什么不用React？团队熟，Vite冷启动快，首屏构建时间比Webpack短60%。
- 为什么不用原生JS？社保查询表单复杂，状态管理（Pinia）比手写DOM操作可维护性强。
- 关键约束：表里要求“首屏≤2s”，Vue 3的Tree-shaking能砍掉70%未使用代码，比React的运行时优化更适合资源受限的政务环境。
后端：Spring Boot + MyBatis-Plus
- 为什么不用Node.js？甲方数据库是Oracle 11g，Java生态对Oracle兼容更稳。
- 为什么不用JPA？MyBatis-Plus的SQL控制更细，方便对慢查询做针对性优化（表里要求“API响应P99≤300ms”）。
数据库：MySQL 8.0（读写分离）
- 主从架构，从库扛读流量。社保查询90%是读，写操作集中在数据同步。
- 关键约束：表里要求“峰值3000QPS”，单库扛不住，必须分库分表。按“身份证号”哈希分16个库，每库16张表。
缓存：Redis Cluster
- 热点数据（养老金标准、社保政策）全量缓存，TTL 24小时。
- 关键约束：表里要求“错误率<0.1%”，Redis Cluster三副本，避免单点故障。

选型铁律：所有技术决策，必须能在《平台网站建设意见征求表》里找到对应指标。找不到，就是过度设计。

核心实现：把“性能优化”写进代码，不是写进PPT

性能优化不是上线后调参，是写代码时就有约束。

案例1：首屏优化——从4.2s到1.8s

问题：首页加载了12个组件，包括“社保政策”“查询入口”“公告栏”等，但用户90%只关心“查询入口”。

错误做法： 所有组件同步渲染，等全部加载完才出内容。

正确做法： 基于《平台网站建设意见征求表》里的“P95首屏≤2s”，做路由级代码分割+组件懒加载。

// router/index.js
const routes = [{path: '/home',component: () => import(/* webpackChunkName: "home" */ '@/views/Home.vue'),// 关键：查询入口组件同步加载，其他组件异步children: [{path: 'query',component: () => import('@/components/QueryEntry.vue'), // 同步，首屏必现},{path: 'policy',component: () => import(/* webpackChunkName: "policy" */ '@/components/Policy.vue'), // 异步},{path: 'notice',component: () => import(/* webpackChunkName: "notice" */ '@/components/Notice.vue'), // 异步}]}
]

<!-- Home.vue -->
<template><div><!-- 首屏核心：查询入口，同步渲染 --><QueryEntry /><!-- 非核心：懒加载，骨架屏占位 --><div v-if="loaded" v-else="skeleton"><Policy v-if="showPolicy" /><Notice v-if="showNotice" /></div></div>
</template><script>
export default {data() {return { loaded: false, showPolicy: false, showNotice: false }},mounted() {// 首屏渲染完，再加载非核心组件this.$nextTick(() => {this.loaded = true// 用requestIdleCallback，避免阻塞主线程if ('requestIdleCallback' in window) {requestIdleCallback(() => this.showPolicy = true)requestIdleCallback(() => this.showNotice = true)} else {setTimeout(() => this.showPolicy = true, 100)setTimeout(() => this.showNotice = true, 200)}})}
}
</script>

效果： 首屏只加载QueryEntry（12KB），其他组件等主线程空闲再加载。LCP从4.2s降到1.8s，符合表里“P95首屏≤2s”。

案例2：API响应优化——从800ms到120ms

问题：查养老金接口，后端要查3张表（个人社保、缴费记录、养老金标准），串行查询，耗时800ms。

错误做法： 后端串行查3次数据库，再拼装返回。

正确做法： 基于《平台网站建设意见征求表》里的“API响应P99≤300ms”，做并行查询+缓存命中。

// Controller.java
@GetMapping("/pension")
public Result getPension(@RequestParam String idCard) {// 1. 先查缓存，命中直接返回String cacheKey = "pension:" + idCard;String cached = redisTemplate.opsForValue().get(cacheKey);if (cached != null) {return Result.success(JSON.parseObject(cached, PensionVO.class));}// 2. 缓存未命中，并行查3张表CompletableFuture<PersonalInfo> future1 = CompletableFuture.supplyAsync(() -> personalMapper.selectById(idCard), executor);CompletableFuture<PaymentRecord> future2 = CompletableFuture.supplyAsync(() -> paymentMapper.selectByLastYear(idCard), executor);CompletableFuture<PensionStandard> future3 = CompletableFuture.supplyAsync(() -> standardMapper.selectByCity("北京"), executor);// 3. 等待所有查询完成CompletableFuture.allOf(future1, future2, future3).join();PersonalInfo personal = future1.join();PaymentRecord payment = future2.join();PensionStandard standard = future3.join();// 4. 拼装VO，写缓存PensionVO vo = buildVO(personal, payment, standard);redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(vo), 24, TimeUnit.HOURS);return Result.success(vo);
}

效果： 并行查询耗时=最慢的一个查询（约100ms），加上Redis写缓存，总耗时120ms。符合表里“API响应P99≤300ms”。

案例3：安全合规——过OWASP扫描

问题：甲方要求过OWASP Top 10扫描，但开发组习惯性地用字符串拼接SQL。

正确做法： 基于《平台网站建设意见征求表》里的“等保二级”，强制MyBatis-Plus参数绑定。

<!-- Mapper.xml -->
<select id="selectByLastYear" resultType="PaymentRecord">SELECT * FROM payment_record WHERE id_card = #{idCard} AND year = #{year}<!-- 关键：用#{idCard}，不是${idCard}，防SQL注入 -->
</select>

效果： OWASP扫描0高危，0中危。等保二级通过。

上线与优化：性能优化是持续过程，不是一次性交付

上线不是终点，是起点。《平台网站建设意见征求表》里的指标，上线后要持续监控。

监控体系：

前端监控：Sentry + Web Vitals
- 监控LCP、FID、CLS，实时告警。
- 告警阈值：LCP>2.5s，持续5分钟，钉钉推送。
后端监控：Prometheus + Grafana
- 监控QPS、响应时间、错误率。
- 告警阈值：QPS>3000，或P99>300ms，或错误率>0.1%，短信+钉钉。
数据库监控：MySQL慢查询日志
- 慢查询阈值：>200ms。
- 每周Review，优化索引或SQL。

上线后第一周的真实问题：

问题1： 查养老金高峰（每月15日），QPS冲到5000，超过表里预估的3000。
- 解法： 临时加2台从库，Redis集群扩容到6节点。
- 反思： 表里“峰值QPS”填低了，下次要跟业务方确认“养老金发放日”是峰值。
问题2： 某浏览器（IE11）渲染异常，布局错位。
- 解法： 表里要求“Chrome 80+, Edge 80+, Safari 13+”，IE11不在范围内。但甲方用户有老员工用IE11。
- 决策： 加IE11兼容层（polyfill），但性能下降20%。跟甲方确认：接受性能下降，还是强制升级浏览器？最终选升级，表里加备注“IE11需手动升级”。