这题目看上去没啥争议或者 bug 啊。答案是 True

-------
命题 P：「[ ]08 x 21 的积是四位数」
命题 Q：「[ ] 里是小于 5 的整数」

下面两个判断：
1️⃣ 若 P ，则 Q 。（这个就是原题目的描述）
2️⃣ 若 Q ，则 P 不一定成立。（例如填 0 也满足 Q ，但 P 不成立）

都是成立的。即，Q 是 P 的必要不充分条件。

所以原题目，也就是判断 1️⃣ 换种说法，的答案应该是「对」。
难道老师觉得可以用 2️⃣ 去反驳 1️⃣？

-------

搜了一下，「命题」的基本概念好像是初中的内容，充分条件与必要条件则是高中数学的内容（参考教材： https://zxkeben.szxuexiao.com/html/4814.html ）

小学生没有相关知识背景可以理解，小学老师至少得有高中以上知识水平吧。

@chairuosen #3 看来不同的人遇到的转账体验差别好大。我用这个中银内地与香港之间同名账户转账，一年来从未遇到过过 2 小时**以内**到账的情况。所以对他们宣称的「最快 5 分钟」完全不以为然。

不过也仅遇到过一次 T + 2 日（限工作日）到账的情况，绝大多数是 T+0 或 T+1 到账。

@TianHeiLeKuaiPao #5 电视如果有两个 HDMI 口的话，接两个盒子（ Apple TV + 一个国产/运营商送的）是不是就行了 😁

@ikichen #113 「手写承诺书及身份证合照拍摄示例」「示例图非真实案例，仅做参考」

@thinkm #34 互留手机号更靠谱的原因是，每个人自己手机上的通讯录是本地的、可导出可备份、分布式的。
避免了「微信好友」这种一旦封号就容易所有联系人都丢失的情况。说白了你的「微信好友列表」是腾讯的数字资产，不是你的资产。

认识新朋友优先留手机号或邮箱，绝对比互留微信号是一种更好的实践。

至于骚扰电话，则是另一个话题。

会员能不能跳过登录时手机短信验证🐶

@julyclyde #15 但你可以换个角度考虑：就 ***去香港*** 这个单一需求而言，深圳北一天 73 趟，福田 34 趟，后者接近前者的一半。
福田一天平均下来也能做到不到半小时一班车，密度还行了。

但深圳北的拥挤程度肯定远超福田的 2 倍吧（因为有很多通往内地其他城市线路），这么看福田的性价比是不是更高 hh🐶 再加上福田在市中心，市区交通也挺便利。

@julyclyde #15 常买车票，当然知道。所以，#13 「如果时间合适的话」

@cssk #10 福田站也是高铁的一部分，比深圳北站更靠近市中心且人相对少，如果时间的合适的话也不失为一个选择咯。

@WonderUniverse #3 甚至从 MacBook Pro 2018 Intel 版就是这样的。

第二段里有个疑问：

1. 假设这一切发生之前，OP 女友的手机锁屏密码为 P

2. 个人理解，当你试图开启 Apple Wallet 中的有关功能时（如交通卡、银行卡），iOS 会检查你的原锁屏密码 P 是否符合强度要求。当且仅当 P 的强度不满足要求（例如不足 6 位数字），iOS 会提示你重新设置更强的锁屏密码（注意不存在 Apple Pay 密码一说，这里是让你重设锁屏密码，这一点你看知乎已经知道了）

3. 但是在本帖第二段中，你说「我当时就没当回事，以为单纯是一个支付密码。输入**原有的手机锁屏密码**后，两次验证，就设定了」。按照我的理解，你这里输入的就是密码 P.
但是按照第 2 点的逻辑，正是因为 P 这个原密码不满足强度要求 iOS 才要求你重设密码的，这里重新输入 P 的话怎么能设定成功呢？ OP 是不是这里记错了

如理解有误请指正。

支付宝，付款码能在 iOS 负一屏使用，超市支付不需要打开 App 。就凭这一点，「国产毒瘤」的帽子我愿给它摘去半顶🐶

系统自带的那个 /usr/bin/java 并不是真正的 JDK, 它只是一个 wrapper 或者说 proxy 或者说 picker ，指向 /Library/Java/JavaVirtualMachines 中（默认为空）某个 JDK 的 java executable.

Stack Exchange: https://apple.stackexchange.com/questions/269588/how-does-usr-bin-java-work-on-mac

@dudewei #26 我没有说这些用户个人资料不重要，我是说如果这些基本信息 E2EE 了，就无法正常进行业务了。

所以要靠内审机制或者内部制度设计。不过即然靠内部制度设计，总可能会有不守规矩的（即使概率较低）。

@stamhe #23 账户资料这个见仁见智吧。我个人觉得对 Apple 或者任何服务商（不限于互联网）来说，这些 Metadata 账户元数据都是它们提供服务的依据，是不会 E2EE 的。（这里的 E2E 的两个 End 都是指用户的设备，也就是说，如果 真正实现 E2EE ，那么厂商根本就无法解密这些资料，也就无法为你提供服务）

就像银行知道你的手机号、身份证号；淘宝也知道你的手机号、收件人地址等。

这些账户资料是你为了获取相应服务而提供的，和「你存储在网盘中的文件 / Key 」性质还不太一样。

即然不 E2EE ，那么就难以从技术上 100% 杜绝内部员工查看这些资料，也就不能 100% 杜绝「员工因为私人恩怨开盒用户」的事情发生。只能靠内审机制尽可能避免吧。

@stamhe 😂怎么说呢，你的担忧是有道理的：因为 Apple 的系统是闭源的，公众没办法证实它是否遵守宣传和承诺，完整实现了敏感数据的端到端加密（你说的 Apple 作为开发商中间人劫持之类，就属于 Apple 它虚假宣传、事实上没有实现真正的 E2EE ）。

由这种担忧，其实可以推广到：不要相信任何闭源的云服务商所宣称的加密机制。因为你没法证实它真的实现了。

====

但是，话说回来，大家在网上的讨论都是基于一些（可能不那么严谨的）假设，否则容易陷入绝对怀疑主义然后怀疑一切、觉得一切都可能是不真实的或者有漏洞，然后讨论终止。

在这个帖子里很多人的 <心理假设> 就是，Apple 自己宣称的对敏感数据的 E2EE 是真的实现了。在这个假设下（再强调一遍，这是假设，当然不强迫每个人接受）再看你在 #2 的发言，直接就把「工程师都能看看你的私钥」当一个确定性结论，这确实就有点儿没道理了😂

#8 给出的链接也意义不明，只说了苹果的员工可以看到用户的邮箱、地址、电话等资料，但这些账户资料 Apple 本来就没说端到端加密。但是 Passkey / Keychain 的存储 <宣称> 是 E2EE 的。你给的那个链接里完全没提到这些 <宣称> E2EE 的资料存在泄露情况。
所以很多人选择相信 Apple/Google <宣称> 的 E2EE ，我觉得也完全可以理解啊。

对续航这一点，我的方案是，减少使用手机的时间🐶

平时工作用电脑；通勤、吃饭等时候以发呆/看风景/闭目养神等代替刷手机。更多地观察大自然和身边的人和事。
工作通讯方面也极少使用微信等 App ，主要在电脑端用邮件（这一点每个人可能工作处境不同）。

手机主要是作为一个生活辅助（通话、支付、点餐等）的工具，不很必要就不拿出来刷。这个用法，甚至 iPhone SE 的电量都能坚持一天。虽然知道大屏新品会更爽，但是仔细想想如果习惯了轻度使用手机，升级的欲望并不太高。（电子产品阳痿了）

只有长途出行或去不熟悉的地方时才带充电宝以防万一。因为频率不高，所以可以接受。