网页调用数据库代码

浏览器里跑JavaScript，网页数据库在服务器上，调用两者隔着一道墙。数据直接连？库代想都别想。MySQL的网页3306端口从不向公网敞开，这既是调用安全底线，也是数据技术常识。所以网页调数据库，库代本质上是网页网页调接口，接口再调数据库。调用

最简单的数据路子是写个PHP文件当中间人。比如你有个用户表，库代前端发个GET请求到getUser.php?网页id=1，这个PHP文件内部用PDO连上MySQL，调用执行SELECT * FROM users WHERE id = ?数据，然后把结果用json_encode吐出来。前端拿到JSON，渲染成页面。就这么回事。我见过不少刚入行的朋友，试图用WebSocket直连数据库，折腾三天后放弃，回来老老实实写接口。

代码长这样——后端PHP：

<?php $pdo = new PDO('mysql:host=localhost;dbname=test', 'root', 'pass'); $stmt = $pdo->prepare("SELECT name, email FROM users WHERE id = ?"); $stmt->execute([$_GET['id']]); echo json_encode($stmt->fetch(PDO::FETCH_ASSOC)); ?>

前端用原生fetch就够了：

fetch('getUser.php?id=1') .then(r => r.json()) .then(user => {  document.querySelector('#name').textContent = user.name; });

别小看这个模式。它撑起了互联网上一大半的动态页面。你刷淘宝、刷微博，每一条动态都是这么来的——前端发请求，后端查库，返回JSON，前端渲染。区别只是把PHP换成了Java或Node，把MySQL换成了PostgreSQL或MongoDB，但骨架没变。

但这里有个坑，新手最容易踩：SQL注入。上面例子用了预处理语句，安全。可要是有人图省事，写成SELECT * FROM users WHERE id = $_GET['id']，那等于把数据库钥匙挂在门口。我见过一个真实案例，某小网站后台被拖库，就是因为登录接口拼接了用户名参数。对方在用户名框里输入' OR '1'='1，直接绕过密码验证。修这个漏洞花了半天，但数据泄露的影响持续了两年。

更现代的做法是用RESTful API。后端用Express或Flask起个服务，定义好路由，前端用axios或fetch调用。这样好处是解耦——前端团队和后端团队可以并行开发，只要约定好JSON结构。比如一个简单的Express接口：

app.get('/api/user/:id', async (req, res) => {  const user = await db.query( 'SELECT name FROM users WHERE id = $1', [req.params.id] ); res.json(user.rows[0]); });

前端调用方式几乎没变，只是URL从.php变成了/api/user/1。这种风格现在更主流，因为前后端分离后，同一个后端可以同时服务网页、App、小程序。

还有种剑走偏锋的方案：用Serverless函数。把数据库操作写成云函数，部署到AWS Lambda或Vercel Edge。好处是免运维，按调用次数计费，适合个人项目或流量波动大的场景。缺点也明显——冷启动延迟可能到几百毫秒，而且数据库连接池管理麻烦。我有次给朋友做个活动页，用Vercel的Postgres，高峰期连接数超限，页面直接502。后来老老实实换回常规服务器。

说回网页本身。浏览器有同源策略，跨域请求要处理CORS。如果你前端跑在localhost:3000，后端在localhost:8080，不设置响应头Access-Control-Allow-Origin，浏览器会直接拦截响应。解决方式要么后端加中间件，要么用代理转发。开发环境用Vite或Webpack的proxy最省事，生产环境用Nginx反代。

最后提醒一句：别把数据库密码写在前端代码里。哪怕你用的是纯静态托管，只要代码进了浏览器，就等于是公开的。正确做法是密码放环境变量，后端读取。前端永远只跟接口打交道。这条铁律，能帮你避开90%的安全事故。

网页调数据库，说白了就是一层请求、一层处理、一层响应。搞懂这个链路，剩下的都是细节。