@kop1989 3#你说的这是后期渲染出来的“图像”，比如文本文字之类的。而 LZ 说的图片，不可能后期渲染，所以原封不动还是 300*300 个点。

但是 LZ 说的这个事，其实是 PPI 的事情。由于 PPI 不一样，所以同样一张 300/300 的图片，在高分辨率的显示器下，只显示了 0.5cm/0.5cm ，像素点更密集了，而人眼还是人眼，视距还是那个视距，缩小的图片，让大脑感觉图片更加细腻。
然后如果一个比较好的看图软件（具有较好的放大算法）在放大 200%的时候，又回到了 1cm/1cm，可能看起来还凑合。
至于 MAC 那个系统级的缩放（把四个点当一个点显示），系统驱动在收到图片后，给显卡渲染的时候，经过了较好的放大算法，所以看起来还是 OK 的。

这边建议还是弄个大滚球，然后弄个左键，弄个右键，然后，轨迹足球。。。

既然如此，为啥非要 base64，或者全都 base64 得了 o(*￣▽￣*)o

OneNote 吧，不要钱，跨平台，还能连微信，可简化用也可复杂用

CarPlay 还算上心，
Android Auto 国内水土不服
CarLife 就是个垃圾
可惜高德不出这东西，iOS 上依托 CarPlay，Android 上人家自己有车机版
不知道华为的车载 OS 会多么上心。

一样的软件，不一样的链路，不一样的速度，问题显然出在链路上啊。
ping 、traceroute 对比一下两个链路的质量吧。
剩下的问题，就是你的路由器调配了。

你猜光子有时间的概念么？没有，因为他是光速，他的时间是静止的，可谓是从诞生到灭亡，就是一霎那的事情。
有了时间，才有了质量，有了质量才有了物质，才有了世间万物。

那么时间可以倒回么？我认为不可以，换句话讲，诞生的光子灭亡后，还能重新回到灭亡前么？不可以，也许这份光子的能量被吸收后（灭亡）又释放了一个光子（诞生），但是这两个光子必然不是同一个。否则，万事万物是不是都是宇宙诞生之初的一个光子呢，永恒不灭？
在这条 X 轴上，只能正向推演，不可停滞不可倒退

因为 V4 网络结构问题，NAT 是一个没办法的办法，然而这个办法导致网络开销，所以 NAT 越少越好，所以对于一个家庭网络来讲，有大神讲过最多一次 NAT，我深以为然。

至于你的实际情况，我说的是，如果允许多次拨号，那就是平行的 NAT，因为某种意义上，你的情况算是两个家庭网络，所以每个家庭网络各有一次 NAT 没什么问题。意即，你说的平行，而非上下级二次 NAT 。
那么现实情况是，你没有多拨，甚至连光猫的桥接模式都没有做，于是必然就会二次 NAT，而且总共会有三个 NAT，一个光猫上的总 NAT，然后二级路由各自平行的 NAT，所以我个人觉得，最好的方案，先把光猫搞桥接，然后两次拨号，各自 LAN 的路由各自拨号。

性能么，我倒是觉得，不能作为次要条件考虑，要在设计网络结构的时候一并考虑，无论是从 300 损耗到 250，哪怕是 300 损耗到 290，都是不应当的。

都涉及到无线设备的，VLAN 能做出来？哦，回炉了一下 LZ 的需求，好像不存在不同的无线设备走不同的出口的情况。

如果三个线路都属于 LAN 形式的，走二层设置 VLAN 确实搞定了，然而不设置 VLAN，三个线路都带有 DHCP，这台交换机里不打架啊。

所以我觉得 LZ 那意思，三个都属于 WAN 形式的，所以存在一层 NAT 的问题，那就只能求助于 iptables 了吧。

刷路由？我曾经用的 asus 的，从来都是用无线刷机的，刷完配置都在。
当然，刷的系统不是底层刷，属于高级别的二开刷机，反正也挺够用的

发现一个交易 https://www.v2ex.com/t/696856#reply7，似乎适合 LZ

两台路由意味着两个 NAT，有人说过家里的网络应该保持一次 NAT，如果你家的宽带允许多拨，那就无所谓了，如果不允许多拨，我觉得还是得一次 NAT，然后利用 MAC 在 DHCP 上做文章。
至于 WIFI 的问题，软路由+AP 应该是一个平衡的方案，回应一下 @HEROic，除非 LZ 干脆梯子用有线，无线不梯子。

@ElmerZhang 那你应该用两个 AP 建两个 5G Wifi，一个走墙内，一个走墙外

@a22271001 大学宿舍床上必备，20 年的老产品了

@visonme 你用的工具不够强大

本人一直从事自身机构的信息化工作，处于甲方多一些，当时行业比较不具有通用性（或者说，理论上的通性我个人还没有悟到），说一点点感受：

1. 无代码 /低代码是我们追求的目标，或者说是一个降低开发成本的好办法。
1.1 自身的业务，找乙方实现，一定需要更高的成本，而且还有时间机会成本等因素
1.2 乙方的素质、能力不可控
1.3 预算投资自身也需要权衡各方，投资毕竟是有限的
1.4 自身是有一部分人员可以通过适当的培训，转化为开发人员，当然这需要开发门槛非常低

2. 客观、科学、准确地分析机构的运行模型，引入适当的工具。
2.1 CRUD 本身确实是数据维护的操作，数据维护操作是核心但不是全部
2.2 类比“程序=算法+数据结构”这个公理，那么数据结构=数据，而算法则是业务，业务操作数据，整个数据的状态体现了机构状态
2.3 业务的实现，本质是什么，需要什么样的工具支撑业务实现信息化，这样的工具有没有低代码 /无代码

3 基于本人对我所在机构以及行业的观察，目前是有这么一个解的，但是回归第一句话，还未完全悟到全行业的通性，所以不知道我的方法论能够推而广之。

@vhwwls 高德地图上，北京很多商场都有分层导航啊，商铺准不准咱不讨论，商铺的变化频率肯定比高德的维护频率高。当然我是没有完完全全按照 LZ 说的去真正地导航，不知道高德做这个行不行。但是作为一个具有智商的人，手上有分层布局图了，知道了目标位置，以及自己位置，还找不到路？
更何况从技术角度讲，这是个多少年前的东西，必须就不是一个技术问题了。至于为什么没做，那完完全全是一个商业价值问题。所以，ㄟ( ▔, ▔ )ㄏ