另外，怕连接数过多的话，单节点配置好最大在线数，新连接进来的时候判断下、超过了就拒绝掉，这个可以在网关或者业务节点的 upgrader checkorigion 里做，更好点的方式是自己 wrap 下 net.Listener，serve(listener)，Accept 的地方直接做

节点数不多、redis 的话，每个节点每秒 hset 、hmget 下就行了，没啥压力，而且实时性也足够

BTW，我这有个 ARPC 的 golang 框架提供了 websocket 聊天的简单示例

https://github.com/lesismal/arpc/tree/master/examples/webchat

另外 ARPC 支持发布订阅，如果想自己实现个管理服务器进行多个服务节点的在线数统计，管理服务器接收上报人数、然后把多节点的业务服在线总和发布就行了

想简单处理的话轮询写、读 redis 就好了

跨站点劫持楼主已经写了，check origin + 业务层认证

单设备连接数限制这个不太合理，通常应该按照身份限制比较好：既然有业务层认证，每个连接都有身份，如果不允许同一个身份多个连接、认证后就把之前的踢掉，如果允许，那就自己服务节点配置提高、节点数量增加之类的（如果怕统一身份的连接散到多个服务节点上，可以加个网关层，网关层按身份指定到实际的业务节点、由业务节点进行踢下线处理）。如果实在是想按照设备限制，那策略里使用身份的地方就改用 ip 或者你的算法能够生成的设备 id

统计人数通常不需要太精确，即使是多个服务节点，每个节点定时（比如 5s ）更新自己节点在线数到 redis/sql 都可以、更新多节点在线数量总和就可以了，实时在线本来就是不停跳动的，精确的意义不大。如果实在要求精确，自己再写个服务进行统计、并且同步到所有节点，或者直接用 redis incr 之类的，每秒查询、更新，但是都没法保证百分百精确，实时的本来就是跳动的数据，即使是股票 K 线的蜡烛图也都是按时间段的起值、止值、最高值、最低值进行统计的

完整的例子可以看这里：
https://github.com/lesismal/pm/tree/master/examples/bind_src_dst

还有个项目是 fork 了个别人的 admin template，用 pm.js 改造了下，可以直接对比 fork 的原作，性能提升太明显了。。
https://github.com/3rdrepo/adminkit

@bmwh123 其实就是把老方案的内容摘出来放到单独的 html 子页面，index.html 里放上对应的 dom 元素，用 pm.bindPages 绑定这些 dom 元素的 id 和对应的子页面 url，可以手动 $pm.select 切换页面 也可以带上 src 配置项在对应的 dom onclick 时自动切换内容，或者配置的 dst 值就用 router，然后 $pm.listenRouter 用路由的方式自动切换，比如：

<div id="menu" class="side_bar">
<div style="height: 2px;">&nbsp;</div>
<button class="button">
<a href="#page_1" class="button">Page 1<br>Click Me</a>
</button>
<div style="height: 2px;">&nbsp;</div>
<button class="button">
<a href="#page_2">Page 2<br>Click Me</a>
</button>
</div>

dom 树上两个 <a> 分别路由到：
href="#page_1"
href="#page_2"

// 页面配置 && 绑定
let pages = [
{
dst: "page_1",
url: "page/page_1.html",
},
{
dst: "page_2",
url: "page/page_2.html",

// lazy 为 true 时则第一次显示时才进行加载，否则进入页面就开始加载
lazy: true,
},
];
$pm.bindPages(pages);

// 显示 page_1
$pm.select("page_1");

// 监听路由变化、自动切换页面，比如路由切换到 #page_2 时，相当于执行 $pm.select("page_2")
$pm.listenRouter();

@alan0liang 是啊，我找了好几个 bootstrap admin template，都差不多的情况。可能这些主要是为了展示 template 功能、没做优化，但是既然是作为 template，别人拿来用也是希望快速实现功能，所以性能问题还是太不友好了。
还有很大程度上其实应该是使用传统原生 js 方式的的老技术、工程体系的锅，react vue 崛起之前的前端社区的大部分人缺少工程思维，react vue 崛起后框架强行工程优化了

not lazy 的是进来就加载的，都可配，业务层自由管理

@bmwh123 抱歉才看懂问题，前面的回答默认以为大家知道实际的机制了呢。。。

实际上单个大页面分为主页面和子页面，主页面里大概是这样子的：

<div class="main">
<div id="nav"></div>

<div id="dashboard.html"></div>
<div id="charts-chartjs.html"></div>
<div id="forms-basic-inputs.html"></div>
<div id="forms-layouts.html"></div>
<div id="icons-feather.html"></div>
<div id="maps-google.html"></div>
<div id="pages-blank.html"></div>
<div id="pages-invoice.html"></div>
<div id="pages-profile.html"></div>
<div id="pages-settings.html"></div>
<div id="pages-sign-in.html"></div>
<div id="pages-sign-up.html"></div>
<div id="tables-bootstrap.html"></div>
<div id="ui-alerts.html"></div>
<div id="ui-buttons.html"></div>
<div id="ui-cards.html"></div>
<div id="ui-general.html"></div>
<div id="ui-grid.html"></div>
<div id="ui-modals.html"></div>
<div id="ui-typography.html"></div>

<div id="footer"></div>
</div>

每个子 div 的 id 对应一个子页面，然后才是上面 lazy 相关的回答，如果 lazy 默认是不加载的、而等用户首次点击触发 $pm.select(...) 或者代码 $pm.select(...) 时才去加载的，并不是进到主页默认就把所有加载进来

@bmwh123 还提供了$pm.release(page)，可以用于释放单个 page 的内容，如果应用层子页面内容太多想减少总资源占用压力，可以根据自己的需要、在 onhide(page) 中选择是否对该子页面内容释放，就是对该 dom 元素的 innerHTML 设置为""。

@bmwh123 有个 lazy 选项，lazy: true 的子页面是等到需要展示的时候才进行异步加载的，比如：

https://github.com/3rdrepo/adminkit/blob/dev/static/js/init.js#L18

每个页面可以配置：

{
src: "pages-profile.src", // 这个 id 的元素 onclick 时会切换内容到 dst
dst: "pages-profile.html",
url: "page/pages-profile.html",
lazy: true, //如果 url 不为空，lazy 为 true 则等到首次显示 dst 内容时加载 url 对应的子页面
init: function() {...}, //首次显示时调用
onshow: function(){...}, //被显示时调用
onhide: function(){...}, //被隐藏时调用
}

@otato 对 hash 路由切换页面内容做了支持，fork 了个 admin 模板项目，用 pm.js 改造了下，去掉了多个页面大量的重复内容、避免不必要的重复加载、重复下载之类的，对比 fork 原作，切换内容顺滑、性能基本能达到极致了

欢迎来指点、给些批评建议（ v 站不让每个回复都带外链，只能加另外一个帖子的链了）：

https://www.v2ex.com/t/747412#reply0

@shunia 感谢之前指出的相关知识点，最近研究了下 history 和 hash 路由，选择了对 hash 路由做点支持、根据路由切换内容，hash 路由确实不算复杂，但是内容管理本身还是需要原来的部分

随便找了个 admin 的模板项目，用 pm.js 、hash 路由切换内容的方式改造了下，去掉了多个页面大量的重复内容、去掉不必要的重复加载、重复下载之类的，切换内容更加顺滑、性能要好太多。我对前端不熟悉，各位交流中指出的问题能方便我更快去找到相关知识点、改进计划。

如有兴趣欢迎多来指点、给些批评建议：

https://github.com/3rdrepo/adminkit

:smile::smile:

随便搜下 “ 硅谷大佬 孩子 手机 ” ，然后再决定要不要给 2 岁半孩子配手机吧，如果还要继续配，那我替楼主心疼孩子 3 秒。

@zlu1123 感谢 star，我还是前端新人，努力学习改进 ^_^

@otato V 站不能编辑，哎，上面一条编辑中、手抖就发了

搜了下 native 相关的，似乎前端社区原生 js 可以叫 native，比如：
https://stackoverflow.com/questions/41948057/native-javascript-vs-jquery-real-world-performance-vs-theoretical-benchmarks/41948449

而 native 对于 react 只是 react 的移动端绑定原生方案，这里的 native 适用范围是在 react 而不是指整个前端 js

各种技术都不简单，不同的社区、框架不同的命名、叫法太多了 😂

@otato 搜了下 native 相关的，似乎前端社区原生 js 可以叫 native，比如：而 react native 只是 react 移动端的、这个只是 react 内部的区分

@otato

“提供单页面方案或者工程性的基础，这不跟我一个意思嘛” —— 对的，就是这个意思

“接下来不是跟你抬杠，只是有些问题你理解错了，首先真没 native 这个说法” —— 我也不确定，不常混前端社区，只是看到有人这么说，以为传统的非 react 、vue 就是 native 呢，多谢指正

“列表渲染 1234” —— 这个例子其实虚拟 dom 不管是哪种实现，如果是通用的功能肯定做不到最佳，当然我也不是追求完全的性能最佳，通常不影响性能体验的小消耗还是便利性优先就行了，至于复杂 UI 之类的，还是交给 UI 框架自己处理吧，否则搞一整套也是个大工程

“这里再次建议尝试一下完整版的 vue” —— 我原计划也是，原生然后 react 和 vue 看看，react 看着有点复杂，暂时也打算 vue 一波，另外就是，前端这几年变化太快了，之前也偶尔看过一波，结果 vue 又说 3.0 了，还不知道 node 爹的 deno 未来会不会带起来节奏、但是目测有点难了，node 已经形成的庞大社区有点船大难调头了

@shunia

也很早就有使用 history —— 这个我不懂，但是它是否需要重新渲染页面？如果不需要，那性能没什么损失，还好

redux 之类的，你觉得简单已经学会，不代表大多数人的感受。我的观点也不能代表所有，但是至少我是这样的感受，并且包括 node 之父自己的一些观点以及 deno 刚出来时候有成都小伙去炸 issue 的时候，或者说现实世界里的前端同事也很多这种感受的。

‘虽然依旧是屎山’ 你写你的框架，我写的 Javascript 屎山关你屁事 —— 我说是屎山，这个是否定早期的前端技术栈，并不是否定写前端的人，我原来的描述里也说了，能把前端做好的确实是值得肯定的。也没有强行提高 go

你可以不想学 Javascript 世界的新东西，这没问题，但是既不去了解，也不做客观的比较，匪夷所思。 —— 我写出来的都是自身感受，如果理解不到位，多指教、交流就可以了

但是，淡定点，聊个技术，不要逮到个字眼就随便自己臆测出别人存在恶意或者曲解别人的含义，气大伤身