@catalina 这语气，这质问。。。好像我是豌豆决策人你要来跟我对质一样。吓尿了。
我是没见过这情况，找了个可能的说法来供参考，一起探讨他们这做法的动机和影响。你这质询找错人了对不起，而且看起来更像气急败坏急火攻心。
不想讨论了。

问了一下前豌豆大佬，流程是这样的：
下载本身没有问题，https 本身可以保障。
安装的时候，某些国产 rom 会偷偷检查应用名，
如果自家应用市场有，那就拦截，实际上安装自家的那份。或者警告你这个包有问题。
所以需要创建一个连不上网的 VPN，实质上断流，来 block 掉 rom 厂商的校验请求。

未验证供参考。

如果你敢说真正的精通，那你对语言、范式、编译器、并发、容器、io。。。无数子话题都非常精通了。漫长过程中难免对触达到的某些方面也会有所涉猎，例如本职工作做游戏，会对算法、2D/3D、架构设计、脚本语言有足够的深入了解。那时候，语言本身已经不太重要，无论精通的是什么，你都是业界大牛。
所以“能力只够精通一门语言”，是伪命题。

然而基于你现在还是学生。。。任何一门语言都不可能做到精通。敢往简历上写这俩字，楼上一堆大牛会直接打死你。21 天精通 xxx 这种程度的“精通”还只能做到一门语言，这能力也只能建议转行了。

所以“能力只够'精通'一门语言”，也是伪命题。

综上，遇到具体事情，选择最合适的。除此之外，选择一门最感兴趣 /最顺手的多深入一些就好了。

梦幻家园，三消游戏，特别减压，有失败次数上限也不会磨掉太多时间。

话说 chm 不应该是纯数据载体格式吗？崩了难道不是 chm 阅读器的锅吗？

另外，Dash 好评。没有用过的 http://overapi.com/ 或许也是一种选择。

这就是“维护越久换人越多，style.css 文件越大”定律。别问我怎么知道的。

如果不是时区，那就是夏令时 /冬令时的锅？

我问领导为啥要这样做，他说，这样方便管理，这个项目很大的，有很多内容，为了以后维护方便，维护某一个模块的时候不需要关心别的模块，
我想了下，好像多模块并不等于必须多工程，一般工程内模块划分有按目录的（ java ），有按文件的（ c/python ），都可以做到方便合理清晰。多库多项目依赖管理和发布版本管理的时候简直罗嗦最好有独立的项目经理和构建工程师来做这破事。

领导还说了，你要是放到了一起，以后我想升级一些包，比如升级一下 Vue 的版本，是不是要对别的包有所顾忌？假如，将来某个模块，用 react 实现会好很多，那我是不是这部分就是直接用 react 来实现？
我想了下，好像升级 vue 这种底层包无论在哪个项目中都是一件非常蛋疼的事情，而项目异构简直是双蛋齐疼。

领导还说，你把这些用了很多次的组件也弄成一个子项目，比如这个「菜单」，别的子项目也需要用到，你抽出来，以后大家用的时候直接 npm install 就可以了
我想了下，好像组件复用并不等于必须子项目一种实现方式。别的项目组 /别的公司 /别的星球的人要用，到时候再针对性的抽就是了。这么早就假设不怕这项目下个季度就死掉吗？

领导还说了，到时候部署的时候，可能是每个子项目一个独立的二级域名或者二级目录，虽然这样弄，模块间的跳转会刷新整个页面，但是莫的关系，你赶紧开工。
我想了下，独立二级目录还好，独立二级域名简直是架构级别重新设计，单一个跨域问题就烦死个人。
————心里 MMP 脸上笑嘻嘻的分割线————
我说，好的好的。

@geelaw #24 我的意思是对比现实世界，除了协议信息“钥匙”之外会有大量协议之外的本征信息逸散出来供我们利用。但在计算机世界 http 调接口这个场景下，ip、referer、ua、时频、参数特征和分布。。。本征信息少很多，而且要么无法利用，要么伪造简单，要么效果不佳。

其实 lz 提出的问题 X 背后，我更好奇的是问题 Y：为什么会有这样的需求场景？原始需求有没有放弃鉴权之外的其他方案？

服从他们的管理 只是老板、项目经理方便项目管理的预设机制而已。很大很虚的一个框。

真实情况呢？还是和地位相关。
如果是真·甲方，你去了就是钦差大臣就是纪委监察组入驻，舔的你不要不要的。什么服从管理，我可以影响你的管理策略你信不信？ 8 点开会我到不了，我建议你把会议时间定到 10 点我不就可以服从了吗？干活是协调出来的，不是由乙方项目经理指派的。连古代皇帝都知道把京官外派应该作为一种“赏赐”安排给手下。
如果是假·甲方。。。抱歉我还真没体验过很难给出经验了。

鉴权 = 识别客户端合法性。你都放弃鉴权了，等于是放弃识别能力了，又怎么要求“识别”自己人和第三方呢？
就像我家大门不需要钥匙推门就进。但我要防贼。这么等价替换的话，你就会发现，你得有一双贼眼，能发现贼身上自带的一些本征：衣着、神情、习惯动作、气味、面相、指纹、DNA。。。
然鹅，以上在 http 世界都可以仿冒，仿冒门槛还挺低，成本和技巧难度远低于 Neal Caffrey 仿冒一个良民。

楼上戳啥链接办理信用卡的，根本都不一定是发卡行给你的短信。。。现在大把的无关个人干这事。编个短信找个号码库附上自己的推荐链接无脑群发，总有一两个真点进去办理的，自己就可以拿到推荐费了。颇丰哦。

熊猫吃短信 + 通知全关 已经一两年了，iOS 除了不能分别设置“过滤信息静默，正常短信通知”小小遗憾之外，体验良好。

css is awsome


新手学习过程中看不到风险很正常。提出优化建议起码证明 lz 进一步思考了。

但 git 不这样设计不是因为 git 蠢，而是因为这样设计是错的：误提交实在是太多太多了。。。

亲身经历过同事误把 密钥.java.bak 提交进仓库，打包，发布，被竞争对手反编译，获取到公司通用算法和我部门密钥，暗搓搓上线我司在线服务的破解版，然后全部门在过年前一天飞机火车汽车逆流回司加班的壮丽事件。
日常岁月静好的代码仓库，也时不时会出现不应当提交的文件。所以需要 code review，需要服务端 commit 钩子，需要定期检查清理。

单就文件的尺度来说，git/svn 是允许你整体提交的，也就是说你无需手动一个个变更点看过来，一把梭提交整个文件。是不是和“提交整个目录”很像？所以 git 不是没想到，而是在方便和危险之间找到了平衡：文件粒度。
但我要求的最佳实践，依然是提交的时候检查精确到行，每个变更都确认需要提交。（你看我没有要求精确到字符已经很人性化很方便啦！）

宽标准=前瞻性=漏洞百出的校验？
严标准=基于现实=无法适应变化？
这两条路都不是什么好路子。
好路子难道不是
基于当前的严标准 + 配置化等易扩展易维护的结构 + 最重要的时时刻刻维护更新 嘛？

protobuf 只是 content 格式而已。
压力测试基于：HTTP 协议，关键因素：服务端容量、请求处理速度、带宽等，没有一个和 content 格式有关。

@TRIKING #6 有鉴于现在新闻、自媒体的糟糕操行，吸眼球带节奏导致的惨案数不胜数。
所以很建议 po 主把“确实收到了”这一重要信息放在标题或者正文里。
毕竟此贴主要是调侃不是维权或者讨伐对吧？

相互嵌套。。。吓我一大跳，申请一个实例直接就爆内存了啊喂！

只是互相关联，互相存一个指针而已。莫慌，莫慌。