本文详解 node.js 与 react 之间通信的多种模式，重点对比 api 调用与服务端渲染（ssr）的区别，介绍 ejs 等模板引擎在同构开发中的应用，并说明其与 php 渲染逻辑的异同。
本文详解 node.js 与 react 之间通信的多种模式，重点对比 api 调用与服务端渲染（ssr）的区别，介绍 ejs 等模板引擎在同构开发中的应用，并说明其与 php 渲染逻辑的异同。
在现代 Web 开发中，React 通常作为纯前端框架运行于浏览器中，而 Node.js 则承担后端服务角色。二者最主流、推荐的通信方式是 基于 HTTP 的 RESTful 或 GraphQL API：React 通过 fetch 或 axios 发起请求，Node.js（如 Express）提供路由接口并返回 JSON 数据。这种方式清晰分离前后端职责，利于团队协作与扩展。
但正如提问者所思——是否存在“非 API”的替代方案？答案是肯定的，主要有以下两类补充路径：
✅ 1. 模板引擎服务端渲染（传统 SSR，类 PHP 模式）
这正是 EJS、Pug、Handlebars 等模板引擎发挥作用的场景。Node.js 在服务端直接将数据注入 HTML 模板，生成完整 HTML 字符串后一次性发送给浏览器。例如使用 EJS：
// server.js (Express + EJS)
const express = require('express');
const app = express();
app.set('view engine', 'ejs');
app.set('views', './views');
app.get('/login', (req, res) => {
res.render('login', { title: '用户登录' }); // 渲染 login.ejs
});
<!-- views/login.ejs --> <title></title>
✅ 此模式与 PHP 的工作流高度相似：请求到达服务器 → 服务端读取数据库/校验逻辑 → 拼接 HTML → 返回完整页面。它无需前端 JavaScript 即可完成基础交互（如表单提交），首屏加载快，SEO 友好，适合内容型或管理后台类应用。
⚠️ 注意：此时 React 并未运行——EJS 渲染的是静态 HTML，不是 React 组件。若需后续交互，仍需额外引入 React 客户端水合（hydration），但这已属于「同构/通用渲染」范畴，复杂度显著提升。
✅ 2. 真正的同构/服务端渲染（React SSR）
使用 Next.js、Remix 或手动配置 ReactDOMServer，让同一套 React 组件既可在 Node.js 环境中渲染为 HTML 字符串（服务端），又能在浏览器中接管交互（客户端）。例如：
// server.js（简化示意）
import { renderToString } from 'react-dom/server';
import App from './src/App.js';
app.get('/', (req, res) => {
const html = renderToString(<app></app>);
res.send(`
<div id="root">${html}</div>
<script src="/client.js"></script>
`);
});
该方式兼顾 SEO、首屏性能与丰富交互，但需处理服务端无 DOM/BOM、数据预取、样式同构等挑战，工程成本高于纯 API 或 EJS 方案。
? 总结与选型建议
- ✅ 优先使用 API + 前端 React：适用于 SPA 应用、需高交互性、团队前后端分离明确的场景；
- ✅ 选用 EJS/Pug 等模板引擎：适合快速构建内容页、管理后台、对 SEO 和首屏速度有要求但交互简单的项目；它本质是 Node.js 对 PHP 模式的能力复现，不依赖 React 运行时；
- ✅ 进阶采用 React SSR（如 Next.js）：当业务同时要求动态交互、SEO、TTFB 优化时的黄金方案，但需投入更多架构与调试成本。
最后需明确：PHP 的默认行为即服务端模板渲染（类似 EJS），而 React 本身是 UI 库，不会自动“替代 PHP”——它是否参与服务端逻辑，完全取决于你选择的架构模式。理解每种通信范式的适用边界，才能为项目选择真正合适的技术组合。
