感谢分享，但是个人认为这种场景下使用服务端渲染意义似乎不算特别大。

1. 生成会比原来多发一次请求，这样本地的用户信息缓存就用不太上了，还是需要等服务端生成后传过来数据，有一定延迟。

2. 不管再怎么高性能高并发，它也仍然需要单独部署占用资源，请求量比较大的时候还是会对整体有影响，不利于优化，能在客户端做的事情还是在客户端做比较好。

感谢，以后再也不发涩图了。

@LeeReamond

它主要面向的人群是非专业客户。

干开发的不都是自己配开发环境跑吗，用得到这个？

运维用这个的话不可控因素太多了，而且部署方式非常局限。

奇怪。。好像刚才发的不可见了？

你不理解的原因，是因为你把 组织 的权限管理定位在了 开源爱好者组织。

实际上，组织 的权限管理设计主要照顾到的是企业 /独立团队等商业化客户，这种客户一般不会存在你假设的这种情况。

你不理解的原因，是因为你把 组织 的权限管理定位在了 开源爱好者组织。

实际上，组织 的权限管理设计主要照顾到的是企业 /独立团队等商业化客户，这种客户一般不会存在你所谓的因为得罪 org owner 被 delete 掉仓库的假想情况。

到浏览器开发者工具看下 ws 传输的数据，它会帮助你找到问题。

snapdrop 如果双方设备都支持 webrtc 的话，会走 webrtc datachannel 完成数据传输，这个传输理论上来说应该是完全内网的(除非打洞失败，需要走 turn)，并通过 ws 交换信令等信息。

如果有任何一方不支持 webrtc 的话，就会走服务器中转，用的也是 ws 。

还有一个可能会影响速度的点是，snapdrop 对文件数据做了分块处理，这在某种程度上会影响实际的传输速度。

最后，个人其实不太建议在国内环境用 snapdrop 做内网传输，这个项目设计有一个不好的点，它是以公网 ip 做房间名的，虽然我也没想到有啥别的方法，但是这么搞在某些国内运营商那边确实不好办。