首先纠正一点，UDP 是不需要回复确认，不是不需要建立连接，可以认为它是单向连接。UDP 因为是单向连接，如果双方要相互沟通数据那么双方都得在公网上，这点反而不如 TCP 。

补上 2 点，就是 BT 下载的方式。
1 ，a 、b 跟 tracker 之间，只会沟通用户 a 、用户 b 的信息，不会传递真正的数据文件。跟 traker 之间的沟通，UDP 、TCP 皆可，不过如果是正常网络那么 TCP 就很浪费。
2 ，a 、b 各自从 traker 获取到对方的信息之后，a 、b 之间就抛开 tracker 直接建立 TCP 连接，然后相互传递文件数据了。a 、b 之间，最少有一个要有公网端口（ NAT 出来的端口也行），否则是无法建立 TCP 连接的。

同源策略是浏览器端的安全控制措施，不是服务器端的，你反代个毛蛋。

划重点：「 B 站，咸鱼等 app 」

不得不提一下，月薪请假，不管按照 21.75 ，还是 22 天计算扣钱，都有坑。比如 10 月请假 19 天，即实际上 10 月一天都没上班，公司照样得发 3 天的工资。这个坑只要过年放假员工多请几天假就会爆出来。正确的做法，应该是：如果出勤天数大于 11 ，那么工资就是{月薪} - {月薪/21.75} * 缺勤天数；如果出勤天数小于 11 ，那么工资就是 {月薪/21.75} * 出勤天数。这个 11 取得是 21.75 的一半，可以按照实际情况去换。

月薪请假，还有一种计算方式是，按照 {月薪} - {月薪/当月应出勤天数} * 缺勤天数，即{月薪/当月应出勤天数} * 出勤天数的计算方式。看起来很公平，但实际上更坑。财务做预算骂娘还是小事。员工 10 、1 、2 月不请假但也不出活，7 、8 月期间该忙的时候疯狂请假，这才是大问题。

@Sting #73
@poorcai #75

楼主的算法，就是日薪 363.6+按照出勤天数计算，但同时又期望了保姆长期干。哪天楼主来兴趣了请假一个月自己带娃，保姆就直接一个月零收入并且还不能另找超过一个月的其他工作（当然实际上保姆会直接不干）。

如果你要按照出勤日计算，那么你不过多久结算一次，都是日薪，最终都是日结。在此情况下，保姆事实上具备随时第二天请假，以及随时第二天就走人的权力，不管你给不给这个权力。实际上来说，通常，能接受按日计算工资的保姆，也只会做短期打算。

要么日薪，剩下节假日的钱，但接受保姆不稳定的风险。要么月薪，节假日当作福利，但是保姆会很稳定。你要保姆长期稳定干，又不给人月薪福利，那是想吃屎。

你这个很明显跟 public static final int FIRST_LINE_HEIGH 没关系，跟 ScreenUtil.dp2px(80) 有关系。

80dp 的高度如果是静态值，那么请直接把它赋值给 FIRST_LINE_HEIGHT 。如果是动态值，那么请不要赋值给 static final 类型的「常量」，给常量设置一个可变值，即使是仅取第一次的值，那也是找抽。

你现在是装了一个权限比操作系统还高的超级后门，它可能确实没干，但它要想干随时就能干。

这种系统，有一个名字更贴切：（公司对员工）零信任防护系统。信任是双向的，公司对员工零信任，员工也要对公司零信任，在装了零信任系统的公司电脑上，不要放任何员工的个人内容，包括笔记这种零碎个人资料。

@wdlth #10 ip-guard 自己就明确区分了数据加密保护跟全盘监控两个级别，你还在这里混淆监控跟数据保护，那是连非蠢即坏都算不上，是实实在在的蠢。

搜索结果上的是摘要，快照是快照，这是两码事。

六，响应式编程，对应的编程概念是「流」，现实概念有个跟起非常像的，「流水线」。如果要搞这个，首先要把「流」搞清楚。Java8 的 Stream 可以用来入门。Kettle 、Spring Batch 可以用来练手。你最起码是 kettle 或者 Spring Batch （高级流应用，不能是一个处理器转发然后又回到普通代码去处理了） 用得比较熟悉了，才能去接触响应式编程。另外，你也可以直接从函数式编程、数据流，这些数学理论入手，不过前提是要先清空 C 、C++、Java 等全部常规编程习惯。

一到五跑题了，留着备用看吧。

一，同异步跟是否阻塞，不是一词两用，而是有关联的两个概念。

二，阻塞针对的不是当前过程，而是使用同一资源的多个过程之间的协作方式。通常都是 IO 比计算慢，故常见的阻塞是针对 IO 的阻塞。一个 IO 通道，如果只允许同时最多一个过程使用它，在该过程使用它期间其他过程只能等，那么这就是阻塞的。如果允许同时多个过程使用它，那么这是非阻塞的。

三，同步异步，针对的是调用者和被调用者之间的协作过程。如果被调用者不做完就不回复，同时调用者还一直等着它，那么这是同步的。如果被调用者没处理完就提前做个特殊回复，同时调用者认可这种特殊回复，那么这是异步调用。如果调用者这收到异步特殊回复之后，又再继续等待这个特殊回复转换成完整回复，那么这是异步之后的回转同步，或者，整体上来说，这还是同步调用。

四，再往外看调用者、非调用者的宿主程序，这时候同异步跟阻塞有了关联。如果把调用者宿主程序认为资源，调用关系——被调用者的执行行为认为处理过程，那么同步调用是阻塞的，异步调用是非阻塞的。

五，同步还是异步，技术上由被调用者决定，但业务上由有调用者决定。如果调用者实时关心回复结果，那么它永远要是同步调用，即使被调用者技术上异步，最终也要通过异步转回同步来变成同步。异步编程中，如何异步从来都不是关键，如何异步转会同步，获取去掉不必要的业务同步，才是关键。

大前提，如果你要区分同一个服务的不同节点实例，那么实例部署的时候当然要用不同的 bootstrap.yaml 。大前提，Spring Boot 和 Cloud 都不管部署（作为云服务的 Spring Cloud Foundry 另说）。

Spring Cloud 是允许你定义 instanceId 的，代码里面根据 instanceId 做区分即可。但是如何在 bootstrap.yaml 中定义 instanceId ，这个是部署的事，要 k8s 或者脚本去负责。

自增用户 ID ，除了暴露用户量，还能暴露啥。如果它本来就是跟用户原本信息，注册时空信息都无关联，只是人工关联上去的一串数字，那么它的信息量就是个代号。这时候任何静态加密，都是画蛇添足而已，不论加密多少遍，它都可以直接拿出来当用户的代号。弄个雪花 ID 或者 HASH ，将其外围统计信息隐藏掉，并方便存储优化即可。

你要真相搞隐藏用户 ID 的安全控制，那应该搞动态加密，即不同时空下的密文不同，还都能通过私钥推导到同一个 ID 。

一、标识、标志，并没有找到来源词根分析，这俩是现代新造词。二、标识、标志的区别不明。三、不论简繁，标准经常妥协与大众实际使用。这种情况下，翻译个蛋蛋。

第一步狗都能干。

第二步，将调研结果整理成产品子项；第三步，平衡用户需要和开发成本，选择做哪些子项：这才是产品经理的核心角色定位。独立开发者实际上很难抽出来产品经理得角色，这个真得找合伙人。

对于团队来说，如果没有第二步第三步，直接就拿开发加班顶上去，这事狗都干不了，得猪狗不如得“人”才能干得出来。对于独立开发者来说，不找个合伙人去给搞第二步第三步，那么非常大的概率是努力到头一场空。

虽然嘴上说着移动为主，但微软的主要营收——企业领域，以及主要非营收市场——盗版 Windows 领域，从来都没有手机系统的份额，导致微软在手机系统上的定位，一直摇摆不定，这是 windows phone/win10 mobile 死亡主因。诺基亚手机一买一卖静亏 50 亿美元外加彻底干死了诺基亚手机，做出这决策就跟玩一样。

一边给用户 100%的控制权——预装都可卸载、权限想不给就不给，一边又走廉价市场，让无良 OEM 厂商跟开发者既没办法赚土豪的钱又没办法坑穷鬼的钱，从而被 OEM 和开发者抛弃，这是 windows phone/win10 mobile 死亡最主要的外部因素。

绑定移动应用跟 UWP ，但 UWP 跟自家 Win32 应用相互干架，这是 windows phone/win10 mobile 死亡的次要外部因素。

友情提示，windows 10 mobile 终止维护时间是 2019 年 12 月，才 4 年前。

第一，谷歌从来都是打广告并且一直是把广告放到第一位的，这是正常的广告，跟百度竞价排名是由质量的不一样的——百度是把广告直接放到搜索结果第一名的。

第二，现在谷歌广告就剩粗体“赞助商广告”这几个字来区分了（以前是特殊背景颜色明显区分的），这几乎没法区分，离百度真是一步之遥了。

第三，谷歌中文领域的广告，那真是没法看，各种牛鬼蛇神。

不举报，那就是不能购买但已购买的可以下载（就算外区购买再切回来下载都行）。有人举报，好一点的就退款 1 年内购买的，当然国内一般都是上演直接消失术的，苹果没必要搞特例。

国内苹果市场本来也不是奔着应用商店去的，这点对苹果的市场影响极其有限，苹果想怎么处理就可以怎么处理的。