不管是谷歌还是苹果，现在的态度就是，认证和合规的成本都赚不回来的开发者不配开发应用。

多陪老人家吃饭闲聊娱乐

可能人家求职目标就是那些许愿式老板，对自己提的 JD 合不合理没点逼数的，一个愿打一个愿挨

不知道你为啥要图这个无依赖洁癖

一种思路是别有这种洁癖，找一个 libjpeg 的绑定库来做，例如 pylibjpeg-libjpeg 。libjpeg 是事实标准，不用担心移植不了的问题，而且也不是大包大揽的库，不会引入复杂依赖

第二种思路是用系统的媒体 api,例如 windows 的 wic 。不过这并不跨平台，得自己写 interprop,不如第一种省事简单

我这边无论微信还是支付宝都是有门槛(20 ，100 甚至 1000 的)而且是几毛钱不到的。

云闪付其实也有，但没门槛，所以常用。

坏处是有些银行不把云闪付当快捷支付，有些银行内的羊毛统计微支抖美京但没有云闪付

有点哗众取宠了

1. 不管是 ios 还是 android 都没说不让获取设备指纹，只是要求这个指纹是可以被用户主动重置的(通常是恢复出厂设置，所以这个操作门槛有点高)

2. ios 查询软件包只能查通过清单列出的 scheme 且上限 50 个，不能用来检测任意已安装应用。前者有很合理的用途，例如调微信支付前检查下微信有没有安装给个出错提示。倒是后者必要性不足且可能用于非核心用途的用户画像分析。android 也有类似限制，play 对申请检测任意已安装应用有额外审核要求

3. 让非专业用户判断这种用途是否必要属于为难用户了，apple 的做法是要求隐私声明并在商店页展示，合理性让 apple 来决定

4. 如果某种权限使用广泛到所有 app 都需要，那请求授权属于骚扰，根本起不了限制不合理使用的效果，参见现在外国网站的 cookies 声明

主要是跟 tpm2 的功能会受限，例如 windows hello 、设备加密。例如最新 edge 会依赖这个来保护浏览器密码和 cookies

虽然我想说 同样功能 pwsh 基本都内置而且不用动不动就扭各种字符串处理

如果有人要冒领证书冒充你的网站，你其实没法阻止问题的发生，因为攻击者和恶意 CA 不需要跟你有任何往来，跟你用哪家 CA 无关。CT 的意义是让你知道你是否有被冒用（这通常还是通过第三方供应商提供的 CT 监控服务实现的）。除非客户端受你控制（你可以决定信任锚而不是让 OS 替你选一批），否则你也没办法阻止冒领证书被客户端信任。

选择支持 CT 的 CA 的意义是让你相信这个 CA 收你钱不是乱搞的，谁都能监督 CA 是不是在乱搞，不然凭啥信任这个 CA 呢。商业证书通常是有 SLA 要求的，通过合同利益，约束 CA 合规，别被主流平台处罚，进而影响用户的可用性，引发索赔。

商业 CA 是要赚钱的，只能被少数平台信任的 CA 的证书是卖不出去的。除非这 CA 完全不按商业逻辑运作非要恶心人，不然主流平台的合规要求是不可能无视的。

普遍支持 zip 是因为 zip 是 apk/apex 的实际底层格式，android 直接提供相关的稳定 api ，所以系统文件管理器基本都顺手支持 zip 的基础功能(zip64+deflate)
7z 没这待遇，要应用自己带 7z 或者 libarchive 实现。

所以工作之余还是得有点兴趣爱好，有点自我评价的能力，不然你就只能玩这套给无产者设计的循环了

@fromshawn 这是早期华米代工的小米手环用的，后面分家就改名了，也不支持后面的非华米型号，更新可以走 play 商店

从某个版本开始，国际版小米运动健康(版本号 i 结尾)不再支持大陆内的服务，必须下国内版。
我强行把地区改成香港也不管用，可能会查硬件销售区域？

跟 edge 学的

android5 是目前几乎所有 app 的“支持”下限，说下限是因为可能根本没在如此低版本的系统上测过，只是工具链逼的，实际可能没法跑。
大概率这盒子还不支持 wifi5 ，所以建议别折腾，买个次新的二手盒子都行。

145G 也不算很大
开发用机两年下来也能用掉这么多空间
现在很多开发工具都直接把*nix 那边的习惯平移过来了，用户目录那些.XXX 目录，不知道混了多少缓存

@changnet
主要是 c 标准缺太多 os 功能了，posix 是相对中立又是 os 提供的东西，在 c/c++标准化吵完细节之前也只能这么干了

@Ketteiron
C/C++也没说绝对向后兼容，更多时候是新旧 abi 都给你留着（例如 libstdc++的 c++11 双 abi ，可以用新库原地替换），但还想新旧 abi 之间互操作就不现实了

@beautyplus
我目前的感觉是，就算用了 SetConsoleCP 和 win10 1903 增加的 activeCodePage manifest ，还是无法避免依赖系统全局 utf-8 开关，必须走 wchar 那一套

@cnbatch
1. 我知道有些系统受 y2038 影响，但工具链应该有条件做到尽力支持，例如，默认行为就是 64bit time_t ，允许最低限度 opt-out 来解决历史兼容
2. 我是没明白为啥都弃坑 mingw32/clang32 了还没解决这个问题，可能单纯没人搞？
3. 预期是依赖 win 系统的自动转换，程序可以不依赖全局 utf-8 开关的状态也能正确显示中文愉快地用窄字符 C/C++，CPython UTF-8 mode 算是相当接近这个目标了
4. 那还行，至少应用侧有方便 opt-in 的方法
6. 因为很多时候会出现新硬件搭配旧系统的情况，出货时间往往决定应用何时无条件停止支持。例如 Intel/AMD 已经停止出货不支持 AMD64(NX,SSE2)的 x86 CPU 相当长的时间，所以主流应用和工具链基本都不考虑不支持 NX/SSE2 的情况了，但 android 这边因为依然有 armv7 的 SoC ，或者 armv8 SoC 搭配 32 位 os 的硬件在出货，所以无论系统还是工具链短期内都不太可能弃坑

我就这么说吧，绝大多数人学 C/C++,直到结课考完试，都没写出过一个能正确支持非 ascii 字符和长路径的程序，哪怕你是用没有任何遗产从零开始的控制台程序。
可能根本没有教材会说怎么处理这事。

我反正不知道跟 native 搭上关系的地方怎么确保集成后能正确处理这些问题，特别是很多组件不是你自己实现的时候。

国内卖了一般都是国外的 CA 根在国内分销，买了时候应该跟你讲明提供哪条证书链的。除非有 GR 需要，不太建议买根是国内的。

商业证书主要是有效期更长可以不搞证书轮替自动化（换言之，风险变成运维人员操作），但 OV 一般也就一年一签，而且像 OSCP/CT 日志/CRL 分发之类的可达性会好些，能更好兼容一些默认要求严格或者信任根过于古老的客户端。EV 的话可能有些特殊系统要求，但 EV 证书通常要求用 HSM 部署，用起来会比较麻烦，一般不需要用这个。

以 Let's Encrypt 为例，目前只提供 ISRG X1 根，十几年前的设备和系统如果没法更新信任根的话就没法用这个。只有 DV ，有效期最长 3m 且将会缩短到 1m ，意味着 ACME 自动化是必须的。CRL 分发点有可能被墙，会导致某些客户端首次握手时间大幅延长。

只考虑现代系统现代浏览器的话没太大区别，基本等于花小钱请个理论上的背锅侠。