dcsuibian

@Newyorkcity 不了解 angular ，但看起来是用了跟 vue 一样的属性选择器实现的，我就按 vue 的猜了。

你写的一个组件，有类似 html 的结构和对应的 css 。它只会给你写的 html 里加上_ngcontent-fqf-c83 属性（和你的组件对应），然后给你写的 css 里加上[_ngcontent-fqf-c83]选择器，你引用的 select 组件内部的 html 里并不会有_ngcontent-fqf-c83 这个东西。

所以，你最终生成的 css 选择器应该是.specific[_ngcontent-fqf-c83] .mat-select-panel 这样的，这样既能给当前组件里面的 select 换样式，又不会影响其它地方的 select 。所以主要问题就是要告诉编译器.mat-select-panel 是子组件里面的，不需要加[_ngcontent-fqf-c83]

@Newyorkcity angular ？搜一下对应的深度选择器语法吧

单身， 衣服是我妈买的

我之前也纠结过，现在认为针对这种缩写形式，可能看成一个单词更好。
参考 Url （ Uniform Resource Locator ）、Id （ Identity ）、Http （ Hyper Text Transfer Prtcl ），虽然是缩写，但含义已经极其明确，你全大写和首字母大写都可以。
个人感觉 Dto 、Vo 、Bo 的形式比较合理。（在一定上下文环境中省略前缀后）变量就是 dto 、vo 、bo （这里要特别吐槽一下阿里的 DO ，如果全小写会变成关键字 do ，所以我用对应的 PO ），要不然变量叫 dTO 、vO 、bO ，总感觉怪怪的。
写到这里，回去看了一下自己的项目，发现目前用的是 UserVO 这种写法，一般对应的变量直接叫 vo ，如果多个 VO 同时出现，那么会写成 userVo ，感觉也挺舒服。。。

个人来说，喜欢 Linux 区分大小写的设计，但考虑收益，在重装 macos 时我选了 case-insensitive 的。
1 、大小写不敏感的设计并没有给我带来太多负面影响，因为绝大多数情况下，我都不会建两个只有大小写有差别的文件（如果不是有人提，我可能一辈子不会注意到 windows 和 macos 是大小写不敏感的，毕竟大小写不敏感不等于没有大小写）
2 、如其它人说的，macos 上 steam 等软件可能会在 Case-sensitive 的环境中出现问题，这是一个明显的减分项
3 、考虑到 macos 和 windows 默认都是大小写不敏感的，那么也就意味着其它人的电脑最有可能是大小写不敏感的，那即使我在用 Linux ，也会尽量避免分享给别人 a 和 A 这样的两个文件
4 、建立 Git 仓库时、npm init 时、设计 api 时，写 maven 的 groupId 时，一般建议使用中划线命名法，所以我大概也已经习惯了
总体来说，我个人感觉，大小写不敏感的设置不会对开发造成明显影响。调整一下你自己的命名方法可能相对来说更好、更方便，收益更佳

看了一下，感觉问题不大。
人家估计没想过要做一个 youtube 的国内版，估计只是“领导让做个网页版，咋做？抄抄 youtube 吧”这种

没坑，这么好的软件，一年才 200 多美元，续费还有优惠，简直是超值

最烂：《超能查派》，真 tm 后悔熬夜看这种 XXX

火星了。2020.1 刚出的时候就装了，更新到现在，翻译的质量已经挺好的了，不是纯机翻
总体来说，装了以后开发效率提升很大（看的懂英文，但没法快速把单词映射到意思）