单页面应用（SPA）的核心并不是只有一个HTML文件，而是把路由匹配、视图渲染、状态更新三件事都放在浏览器端完成。用户点击导航时页面不发生完整跳转，JavaScript拦截地址变化，局部替换内容区域。这种方式能带来接近桌面应用的流畅体验，但也对原生开发提出更高要求。理解这些核心技术的实现原理，有助于脱离框架也能搭建可维护的HTML在线SPA。
前端路由：Hash与History的差异
Hash路由是最早被广泛使用的SPA路由方案。它的原理是利用URL中#后面的部分不会被发送到服务器这一特性，通过修改location.hash改变地址，同时监听hashchange事件来触发视图更新。举例来说，地址从index.html#/list变为index.html#/user时，浏览器不会重新加载页面，只会触发一个事件。这种方式兼容性极好，即使是很老的浏览器也能正常工作，而且不需要服务端做任何配置。
History路由则使用HTML5提供的history.pushState和history.replaceState方法。这两个方法可以改变浏览器地址栏的路径，但不会导致页面跳转。例如调用history.pushState({}, '', '/list')可以把地址改为/list，同时保持当前页面不刷新。用户点击后退按钮时，会触发popstate事件，开发者在这个事件里重新渲染对应路径的内容。History路由的优点是URL更干净，没有#号，更符合传统网站的审美。但它的缺点是刷新页面时浏览器会真的向服务器请求这个路径，如果服务端没有配置回退到入口HTML文件，就会出现404错误。
下面是一个基础的Hash路由实现，展示了路由表、事件监听和内容替换的完整流程：
const routes = {
'/': () => '<h1>首页</h1>',
'/list': () => '<h1>列表页</h1>',
'/user': () => '<h1>用户页</h1>'
};
function resolveRoute() {
const hash = location.hash.slice(1) || '/';
const render = routes[hash] || (() => '<h1>404</h1>');
document.getElementById('app').innerHTML = render();
}
window.addEventListener('hashchange', resolveRoute);
window.addEventListener('DOMContentLoaded', resolveRoute);
History路由的实现与之类似，只是把hash换成pathname，并且需要拦截页面内带data-link属性的链接点击，调用pushState而不是默认跳转。服务端则需要增加一条规则，把未知路径都重写到入口HTML文件，这样刷新列表页时也能正确加载应用。
视图渲染与事件委托
在线SPA的视图更新通常不会直接操作大量DOM节点，而是围绕一个核心容器进行局部替换。最简单的方式是使用innerHTML把模板字符串写入容器，比如document.getElementById('app').innerHTML = view()。这种方法上手快，适合原型验证。但直接替换整个容器的缺点也很明显：如果页面中存在输入框，每次更新都会丢失焦点；如果页面里有视频或音频，刷新内容还会打断播放。更严重的是，每次innerHTML写入都会销毁并重建内部所有DOM节点，频繁更新时性能会明显下降。
组件化渲染是解决这类问题的有效手段。开发者可以把页面拆成独立组件，每个组件只负责自己的render函数和事件处理。一个组件的render返回一段HTML字符串，再由容器统一写入。事件绑定则不建议写在每个子元素上，而是采用事件委托的方式，把点击、输入等事件监听绑定在容器上，通过event.target判断实际触发元素。这样即使内部DOM被替换，事件监听依然有效，不必每次都重新绑定。
以下是一个简单的列表组件示例，它把数据映射为列表项，并通过事件委托处理删除操作：
function createList(state) {
const items = state.items.map(item => {
return '<li data-id="' + item.id + '">' + item.name + '</li>';
}).join('');
return '<div class="list"><ul>' + items + '</ul></div>';
}
function render() {
const html = createList(store.state);
document.getElementById('app').innerHTML = html;
}
document.getElementById('app').addEventListener('click', function(e) {
const li = e.target.closest('li[data-id]');
if (li) {
const id = li.getAttribute('data-id');
store.removeItem(id);
}
});
这种模式虽然看起来简单，但已经具备了组件化思想的基本形态。当应用变大时，可以继续抽象出组件注册表、生命周期钩子和差异更新机制，逐步向现代框架靠近。重要的是理解每次视图更新的边界，避免不必要的全量重建。
状态管理与数据绑定
一个SPA往往包含多个组件，它们可能同时依赖同一份数据。例如导航栏显示购物车数量，商品列表也展示加入购物车状态。如果每处都维护独立的数据副本，改一处忘一处的问题会频繁出现。因此需要一个集中式的状态存储，统一保存应用运行过程中的可变数据。组件不直接修改状态，而是通过约定的方法触发状态变更，再由状态层通知相关视图重新渲染。
发布订阅模式是实现状态同步的经典方案。状态对象上挂载一个listeners数组，每次修改状态后遍历调用所有订阅者的回调函数。订阅者通常是各个组件的render方法。当状态通过setState更新时，自动触发一次全量或局部渲染。现代浏览器还提供了Proxy对象，可以直接拦截属性读写操作，开发者不需要手动调用setState，只要像普通对象一样赋值，响应式系统就能感知变化并通知视图。
下面是一个基于Proxy的简易响应式状态示例：
function createStore(initialState, onChange) {
return new Proxy(initialState, {
set(target, key, value) {
target[key] = value;
onChange(key, value);
return true;
},
deleteProperty(target, key) {
delete target[key];
onChange(key, undefined);
return true;
}
});
}
const state = createStore({ count: 0 }, function() {
document.getElementById('app').innerHTML = '<p>当前计数：' + state.count + '</p>';
});
这种自动追踪的机制让业务代码更简洁，但需要注意Proxy只能拦截第一层属性变化，嵌套对象的深层修改需要递归包装。此外，频繁触发渲染也可能带来性能开销，实际项目中可以加入防抖或批量更新机制，把同一轮事件循环中的多次状态变更合并成一次视图刷新。
路由守卫与懒加载优化
SPA的权限控制通常发生在路由切换阶段，而不是页面渲染之后。路由守卫是一个在进入目标路由之前执行的函数，它可以检查登录状态、用户角色或表单是否保存，再决定是放行、重定向还是取消跳转。以History路由为例，可以在navigate函数中先调用守卫逻辑，判断通过后再执行pushState和resolveRoute。这样就能避免未授权用户先看到页面再被跳走的闪烁。
懒加载则是针对首屏体积的优化手段。如果把所有页面的组件代码都打包在一个文件里，应用启动时间会随着功能增多而变长。使用动态import()可以按需加载对应路由的模块，首次加载只下载入口部分，访问到某个页面时才去请求该页面的脚本。加载完成后缓存起来，下次进入无需重新请求。浏览器开发者工具的网络面板里能看到，切换路由时才出现新的脚本请求。
以下代码展示了如何在路由表中配置懒加载：
const routes = {
'/list': async () => {
const module = await import('./views/list.js');
return module.render();
},
'/user': async () => {
const module = await import('./views/user.js');
return module.render();
}
};
async function resolveRoute() {
const path = location.pathname;
const route = routes[path];
if (route) {
const html = await route();
document.getElementById('app').innerHTML = html;
}
}
部署这类History路由的SPA时，要确认服务器配置了通配回退，不能只配置/路径。像Nginx需要设置try_files $uri $uri/ /index.html，Apache则需要开启重写规则。缓存策略上，入口HTML文件建议使用协商缓存，保证更新及时；而拆分出的懒加载脚本可以使用强缓存配合内容哈希文件名，这样页面既能快速加载，又不会出现更新后仍然使用旧代码的问题。