抓个包，看下是不是有这个请求头，可能是 webview 层拦截了。

如果 class 和 DOM 有唯一对应性，其实利用 SASS 的嵌套结构或者直接 css 的后代选择器重复 parent 路径也未尝不可，啰嗦了一点罢了，但也是体现了 DOM path ，额外增加的权重也无所谓啊反正你是一一对应不是。

如果不想嵌套选择器，那 BEM 命名就很好呀，也不用缩进了。

我觉得这不成问题的主要原因还是，前端都在搞组件化，样式都变成 scoped 的，随组件一起管理。全局样式文件里就最基本的 reset, typography 相关的。你说的 class 和 DOM 对应的样式，都在组件里放着，组件拆得细，单个样式表就非常小。组件范围内要定位 class 对应的 DOM 就非常简单啊。稍微大一点的组件，BEM 或者 SASS 嵌套就搞定了。

缩进体现层级的方案在传统的多页应用里可以实践，但 Vue, Angular, React 里完全没必要。

还有记得 prevent 掉 tab 键的默认效果，把用户锁住。

事件冒泡，然后在这个引导组件里监听 body ，判断是否点击了要点击的元素，这样就不至于要塞 hook 到实际的业务代码里了。

至于遮罩，现代 CSS 对付这点儿事还是小菜一碟的，mask clip-path 兼容性都很好。

@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 更高，人眼看到的效果就是更精致细腻。