@mikeven 国内闭眼买房躺挣的时代肯定是过去了，但是好房子仍然是抵抗通胀的最佳选择。

有人说房贷利率高，一半在还利息，但是你放在 30 年的周期看其实还是不亏的。货币贬值，物价上涨，最低工资也在涨啊，用将来的钱还曾经的贷款，是划算的。你钱拿手里不做任何理财的话，按 4%通胀算， (1 -0.04)^10 = 0.664 ，10 年后就只剩当时的一半多一点了。银行活期和短期定期肯定是跑不赢通胀的，股票和基金风险更大。比起来房产真的稳定很多，又有居住属性，也能省去你自己租房的钱。

有人说房产增值不关房主的事，因为你就一套房用来住。你欠银行的钱就那么多，房产增值不就是你的净资产在增值么。


买房住肯定比租房好啊。租房子你就不会想着置办大件东西，因为你总要考虑搬家好不好带。一年一个甚至好几个据点，这座城市永远不会给你带来归属感。

负债不可怕，净资产是正的就行。只要我银行账上是负的，通胀就是对我有利的。

@charlie21 外汇不通货膨胀么？你看看现在哪个国家不通货膨胀！疫情美国加印了那么多美元，美国最新披露的年通胀率都达 7%了！全球遭殃。

个人看来，买房其实是最保险的理财方式。我说的理财不是暴富，而是保护自己积累的财富不被通胀稀释。

确保钱在手里要能跑赢通货膨胀，否则你就是在亏钱。背负贷款其实不可怕，多年的通胀翻滚下来，其实银行的利息不算什么的，况且还有公积金贷款。房贷是大多数人人生中能借到的最大一笔钱，一定要好好利用这个机会。

是否依赖 state 的 immutability 完全取决于你的 state 在 view 中具体是如何使用的。

你写一个 pure component 接受 person 对象作为 props, 然后放到你的 personList.map 里 render 试试。

这 routerLink 数据量能有多大？上万？十万？遍历抗得住的。

看起来你这是要渲染导航栏，要不就不追求合并 badge 数据到树结构里？渲染导航节点的时候自己拿 url 去那个 map 里查有没有 badge 呗？

@xiaohantx 不用，生成的图片暂时放内存里就行。

大家都不审题啊，楼主没说浏览器为什么要同源策略，楼主是说为什么浏览器不能一刀切死，每个网站一个沙箱，大家各自井水不犯河水。

同源策略就是一套带着枷锁跳舞的规则，一方面要给到开发者一定程度的自由，一方面还要保证安全性。

运行时让使用者引入，那你的库就是个 Vue 组件库，参考其他 Vue 组件库写法就行。

运行时包括在库里，那就把你写的组件库套一层 Vue App 初始化的代码，向外暴露一个普通函数就行。

@jobmailcn 不好意思，是说没有电脑的情况下啊，那需要手机版本的代理抓包工具 Packet Capture 这个 App 可以，抓 ssl 只需要导入 App 的根证书即可，无需 root.

@jobmailcn PC 上开 fiddler, 安卓导入 fiddler root cert 然后安卓接入 PC 同一局域网，无线网络连接里 http 代理指向 PC 上的 fiddler 8888 端口，就可以顺畅拦截手机上的所有 https 请求啦。

当然 RouterModule.forRoot/forChild 是可以接受动态生成的 Routes 配置的，但是你的数据要在 Router Module import 之前就准备好，而且正如你说的从 API 数据到前端组件类型的映射绕不开，写起来会不优雅。所以，莫不如不追求动态注册，而是用 Guard 控制可访问性。

换个思路，不能动态注册，那控制路由是否可访问是一样的。

后端不直接管辖菜单列表，而是管理用户的 Permission List, 前端再把 Permission 和路由对应起来，可以一对一也可以一对多。路由配置上有 canLoad 和 canActivate 两种 Guard 可用，把要检查的权限放路由 data 字段，permission guard 里检查用户权限是否匹配目标路由所需权限来决定是否放行。至于你的 menu list 组件展示问题，当然也可以根据用户权限来动态生成。

1px 在 dpr=2 的情况下会感觉粗，不是跟 dpr=1 的情况比会更粗，而是和设计稿件比，会更粗，不够细腻，实际你的设备若是高分屏的话是有能力显示更细腻的线条。0.5px 在高分屏渲染出来的线条和非高分屏下 1px 渲染出来的确实都是相同的物理像素，但是他们占的物理尺寸不一样，也就是你说的像素更密集。像素更密集也就是 PPI 更高，人眼看到的效果就是更精致细腻。

Device pixe rate 是浏览器设置出来，并非屏幕硬件参数，更别说浏览器离真实屏幕参数还隔着操作系统层 /驱动层。所以一块 dpr=2 的屏幕这种说法是错误的。

@nanxiaobei 不不不，它就是重点的。现如今的几大框架解决的最基本问题就是，怎么更新数据，数据更新了怎么通知 UI 更新。这是他们最大的区别，其他的东西，你有我也可以有，一个库的事。但是数据到 UI 的更新逻辑，是几大框架最大的壁垒。

@nanxiaobei 这么说吧， 在你的例子里如果是有个 if 条件判断才更新 count, 你的 render 调用是放 if 里吧？后来需求改了 加了 else ，else 里还有个 setTimeout 里面更新了 count, 是不是得记得 count 一赋值得记得调用 render ?那实际的业务场景可能更复杂，很多变量交织判断再赋值，你还跟踪什么时候要调用 render 吗？需求又突然改了，原本某个变量只是在逻辑里用了，后来在 UI 里也用到了，那还要捣回去检查这个变量的赋值操作后是否有 render 调用？那解决方案是什么？保底起见都调用一次 render ? onClick 里面 setTimeout 也得这么干不是？嵌套的异步都得记得调 render, 万一里面改了某个变量 UI 里用到了呢？

@nanxiaobei 你这个漏了，忘记调用 render 的话 UI 就不更新了，很容易出莫名其妙的 bug ，所以最后就成了到处调用 render ，比如 onClick 里套 setTimeout setTimeout 里再 xhr , xhr 回调里判断返回值，再更新 state , 最后你得记得调用你所谓的 render 函数。而 React 说的是你用我规定的方法更新 state ，更新 UI 的事我帮你干了你不用操心。


其实 Angular 的脏检查就是这个方法啦，Angular 会 hook 到所有可能的回调接口，你直接跟常规 js 一样改你的变量，Angular 帮你做脏检查 update UI , 是没有心智负担的。Svelte 的做法是编译插入代码以触发 UI update 逻辑。Vue 是 defineProperty / Proxy 做到你改 data 它帮你更新 UI.

而你的方案是需要使用者自己 call 一个方法来触发 UI 更新，漏了的结果就是 UI 和变量的值不同步，秉承多调用一次没什么大问题的想法，那结果就是每层异步逻辑都要记得调用这个更新方法，虽然有 async / await 会好些。

这就是我不明白的地方，你规避了 React 的缺点，但似乎又引入了更严重的问题。

个人鄙见哈。