html页面跳转时无法直接获取数据库数据，只能传递后端加工后的标识（如id、token）或临时存储轻量数据；应通过api请求、sessionstorage或服务端渲染等方式安全传参，严禁在url中暴露敏感信息或原始数据库字段。
HTML 页面跳转时怎么拿到上个页面传来的数据库数据
根本拿不到——浏览器里没有“数据库”这个东西可传。所谓“带过来的数据库”，实际是后端服务里的数据，前端 HTML 页面只能收到经过加工、序列化后的结果（比如 ID、JSON 字符串、查询参数）。关键不是怎么“取数据库”，而是怎么安全、可控地把后端已查好的数据或线索，从前一个页面传到下一个页面。
window.location.search 能拿到什么、不能拿来干什么
这是最常被误用的地方：很多人以为在 URL 里拼个 ?id=123，下个页面就能直接连上数据库查出整张表。其实它只给你一个字符串，而且只包含你手动塞进去的部分。
- 能拿到：
id=123、token=abc123、type=user这类键值对（需用URLSearchParams解析） - 不能直接用来：
SELECT * FROM users—— 浏览器没数据库驱动，也没权限 - 别硬编码敏感字段：
?user_id=123&password=xxx是典型错误，URL 会留在历史记录和日志里 - 长度有限制：多数浏览器对 URL 总长限制在 2000 字符左右，别传大 JSON
后端接口才是真正的“数据源”，前端只是中转站
真正该做的，是在跳转前让后端准备好数据，或留好“取数凭证”。常见做法有三种，选哪种取决于场景：
- 跳转时只传轻量标识（如
user_id=456），新页面用fetch('/api/user/456')主动拉数据 —— 安全、灵活，但多一次请求 - 上个页面用
sessionStorage.setItem('user_data', JSON.stringify(obj))存临时数据，新页面用sessionStorage.getItem('user_data')读 —— 零请求，但只限同域、且关掉标签页就丢 - 服务端渲染跳转（如 Express 的
res.redirect('/profile?token=xyz')），再由后端用token查库并注入 HTML —— 数据不经过前端 JS，最安全，但要后端配合
为什么 localStorage 不适合传跳转数据
看起来方便，但容易埋雷：
立即学习“前端免费学习笔记（深入）”；
- 生命周期太长：
localStorage持久存在，用户反复跳转可能读到旧数据，没清理机制 - 跨标签污染：同一个域名下所有标签页共享，A 标签页存了订单数据，B 标签页跳转时误读，显示错信息
- 没自动过期：
sessionStorage关闭标签页即清空，更适合“一次跳转”的语义 - 别存原始数据库字段名：
localStorage.setItem('users', '[{"id":1,"pwd":"123"}]')—— 密码明文、结构暴露，后端字段也不该裸露给前端
真正难的不是怎么传，是怎么界定“谁该负责查库”——前端永远不该持有数据库连接或 SQL 能力。传的是钥匙（ID/token），不是金库本身。最容易被忽略的一点：后端返回的数据格式和字段权限，必须和前端预期严格对齐，否则 data.name 突然变成 data.full_name 或直接缺失，JS 就会报 Cannot read property 'name' of undefined。
