























网页设计(Web开发)从早期的“面条式代码”演进到今天的前后端分离、Serverless架构,大致可以分为以下几个典型阶段。每个阶段都有鲜明的代码组织方式、文件架构和性能优化重点,你提到的“ASP/PHP/JSP混合编写”、“关注增删改查”以及“翻页优化、极致压榨单机性能”都可以对应到其中。
代表技术: ASP、PHP、JSP(Servlet 早期)、Perl/CGI
核心特征: 服务器脚本和 HTML、CSS、JS 全部混写在一个文件里。
文件架构:
几乎没有架构可言。一个 .asp / .php / .jsp 文件里,从上到下依次是:连接数据库 → if/else 处理表单 → 拼接 SQL → while 循环输出 <tr><td> → 最后带上一点 <style> 和 <script>。网站的目录就是一堆这样的“页面脚本”,按功能名存放,比如 list.php、add.php、edit.php。
关注点:
主要就是 增、删、改、查。开发只要能“把数据取出来显示”、“把表单提交存进数据库”就完成任务,几乎没有业务层、表现层的区分。
翻页与性能:
翻页直接在 SQL 里 SELECT * FROM table LIMIT 0, 20,很多时候连索引都不建。数据量小还能跑,一旦数据上万,LIMIT 100000, 20 这种深分页就会导致全表扫描。优化手段非常原始:给常用查询字段加索引、做 MySQL 调优、输出静态化 HTML,都属于“单机打补丁”的路子。
这个阶段就是你所说的 “CSS、HTML、JS 混合写在一起,主要关注增删改查” 的典型时期。
代表技术: Struts、Spring MVC、CakePHP、CodeIgniter、Smarty、JavaBean+JSP
核心特征: 业务逻辑、控制流程和视图开始有意识地分离,模板引擎取代了原始的“脚本式 HTML”。
文件架构:
项目开始有清晰的目录划分:
/controllers
/models
/views (或 /templates)
/libs
控制器负责接收请求、调用模型、返回数据给视图;模型封装 SQL 和业务规则;模板引擎(如 Smarty、JSTL)负责用专门的语法循环、判断,不再在 HTML 里写 mysql_query。CSS/JS 逐渐独立为外部文件,不再内嵌。
翻页与性能优化(对应“极致压榨单机”):
数据量上去后,开始对 翻页类操作进行深度优化:
SELECT id FROM ... LIMIT 100000,20,再用子查询取完整数据,避免回表扫大量行。.html,通过 Nginx/Apache 直接返回,动态部分用 AJAX 小范围加载。这个阶段完美对应你说的 “处理海量数据时主要针对翻页类进行优化,极致压榨单机服务器的性能,极致优化代码”。
代表技术: jQuery、Prototype、DWR、早期 Ext JS
核心特征: 页面不再整页刷新,通过 AJAX 和 JSON 实现局部更新,前端开始承担更多交互逻辑。
文件架构:
仍然以服务器端 MVC 为主,但 views 下开始有专门输出 JSON/XML 的“接口视图”,前端多了一个 js/ 目录,里面是各种 jQuery 插件和手写的 AJAX 调用。后端控制器会判断请求类型,如果是 AJAX 请求,就返回 JSON 而不是 HTML。
前后端代码还混在同一个项目里,但逻辑上已经在分离。
翻页演进:
列表页变成“无刷新翻页”:点击下一页按钮,jQuery 发 AJAX 请求,拿到 JSON 后在前端用字符串拼接或简单的模板(如 jQ Template)重新渲染表格。后端分页逻辑仍然在那,但交互体验大幅提升。
性能关注点:
代表技术: AngularJS、React、Vue.js,搭配 Webpack/Grunt/Gulp,后端 Spring Boot、Express、Laravel 提供 REST API
核心特征: 前端彻底成为独立工程,后端只提供数据接口,浏览器端承担路由、渲染和状态管理。
文件架构:
两个完全独立的代码仓库:
frontend/
src/
components/
pages/
services/ (API调用)
store/ (状态管理)
package.json
webpack.config.js
backend/
controllers/ (API 控制器)
models/
services/
routes/
前端项目有自己的构建、编译、打包流程,最终产出一个纯静态的 dist/,部署到 CDN 或 Nginx。后端输出纯粹的 JSON(RESTful 或 GraphQL)。HTML、CSS、JS 再也不同服务器代码混在一起。
翻页与海量数据的应对:
LIMIT offset, size 深分页问题在 API 中依然存在,常用解决方案:游标分页(cursor-based pagination),比如根据最后一条记录的 id 或时间戳来取下一页,避免 offset 偏移。scroll API 或 search_after)。代码优化重点:
前端:代码分割、Tree Shaking、虚拟滚动(处理长列表)、Service Worker 缓存。
后端:热点数据缓存、异步处理、数据库连接池精细化调优,但整体已经转向分布式架构下的吞吐量优化,而非纯粹的单机。
代表技术: Next.js、Nuxt.js、SvelteKit、Remix
核心特征: 在享受 SPA 开发体验的同时,解决首屏加载慢和 SEO 问题,部分渲染重回服务器端。
文件架构:
前端框架内自带“页面路由”和“API 路由”:
/pages
index.js (可做 SSR/SSG)
products/[id].js
/components
/lib (公用逻辑)
/pages/api (自带 serverless 函数)
一份代码既可以生成静态页面,也可以在请求时在服务器端渲染,还能在客户端交互。前后端的边界再次模糊,但代码组织和分工依然清晰。
翻页与性能:
列表页常采用 SSG + 客户端请求 的模式:前 N 页静态生成,后续页通过 API 客户端加载。利用 ISR (增量静态再生成) 定时更新静态页。
极致优化集中在首屏速度和 CDN 边缘缓存上,服务器端性能压力转移到构建和渲染服务上,弹性扩缩容变得普遍。
代表技术: Vercel、Netlify、Cloudflare Workers、Next.js Edge Runtime、Supabase/FaunaDB 等 BaaS
核心特征: “服务器”概念进一步淡化,前端通过静态托管 + 无服务器函数 + 边缘节点直接完成业务。
文件架构:
依然以现代前端框架为基础,动态能力由部署平台提供的函数和边缘计算承担。项目结构更偏向“按需组合服务”。
翻页与海量数据:
数据库本身提供分页能力(如 Supabase 的 range 查询),或者通过边缘函数直接访问全球分布的数据库(如 Cloudflare D1、Fauna)。你不再需要关心单机能压榨多少,因为伸缩在云上自动完成。深分页优化更多体现在 API 设计(限流、键集分页)和前端虚拟列表上。
总结你提到的几个现象在演进线上的位置:
每一个阶段都不是突然出现的,而是在海量数据、高并发和用户体验需求的推动下,代码组织方式、文件架构和优化重点不断演化的结果。
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。