打开一个老项目的前后代码仓库，你会发现index.php里混着HTML、分离PHP和SQL查询，前后改个按钮颜色得翻三个文件，分离调个接口返回格式要同步改前端模板——这就是前后前后端不分离的日常。它没死，分离很多内部系统、前后遗留项目、分离甚至某些快速原型还在用这套模式。前后理解它怎么开发，分离比争论它好不好更有用。前后

先看请求怎么走。分离浏览器发来一个GET /user/profile，前后服务器端的分离路由（可能就是一个if-else或者简单映射）直接命中某个PHP或JSP文件。这个文件从头到尾执行：连数据库、前后查用户表、拼HTML字符串、echo出去。没有JSON，没有API层，浏览器拿到的就是完整页面。后端开发者同时是前端开发者，模板引擎（比如Jinja2、Thymeleaf、Blade）负责把数据塞进HTML里，但逻辑和视图的边界很模糊——你经常能在模板里看到数据库查询或者业务判断。

具体写起来什么样？拿一个用户列表页举例。控制器方法里先查$users = $db->query("SELECT * FROM users")，然后include 'user_list.php'。user_list.php里写<?php foreach($users as $u): ?>，接着是HTML表格标签，中间穿插<?php echo htmlspecialchars($u['name']) ?>。分页？要么在SQL里LIMIT，要么在模板里算页码链接。搜索？表单提交到同一个URL，PHP判断$_GET['keyword']是否存在，存在就改SQL的WHERE子句。整个流程一气呵成，没有跨域，没有CORS，没有前端构建工具。

这种模式有个明显好处：状态管理简单。用户登录后，服务器直接渲染出带用户名的导航栏，不需要前端再发一次请求拿用户信息。表单提交后，服务器可以立刻返回带错误提示的同一个页面，不用前端做表单验证的二次同步。对于内容型网站、后台管理面板、或者团队里只有一两个全栈开发者的情况，这种开发速度反而快。我见过一个内部工单系统，前后端不分离，三年迭代下来，代码量比同类前后端分离项目少40%，因为省掉了API文档、类型定义、前端状态层。

但坑也在这里。前端想做个局部刷新？得用AJAX请求一个返回HTML片段的接口，然后innerHTML替换。这个接口和整页渲染的接口往往是两套代码，容易不同步。移动端要复用？对不起，后端返回的是HTML，App没法直接用。更麻烦的是调试：一个bug可能出在PHP逻辑、SQL查询、HTML结构或者CSS样式，你得在同一个文件里来回翻。团队协作时，前端改个class名可能覆盖后端刚写的样式，后端改个变量名可能让前端模板报错。

实际开发中，大家会摸索出一些约定。比如把业务逻辑抽到单独的PHP类里，模板只负责展示；或者用布局文件（layout）和片段（partial）来复用HTML。但本质上，你还是在服务器端拼字符串。缓存策略也简单粗暴：整页缓存或者不缓存。想做个骨架屏？不存在的，浏览器白屏等到服务器返回完整HTML。

如果现在要接手一个前后端不分离的项目，先别急着重构。看看请求量、团队规模和迭代频率。日活几千的内部系统，继续用这套模式维护成本更低。真要改，可以从某个独立页面开始，后端加一个返回JSON的路由，前端用fetch拿数据，慢慢把视图层剥出来。但记住，前后端不分离不是技术倒退，它只是另一种权衡——把复杂度放在服务器端，换来了部署简单和开发直接。