日本全球前几的长寿在医疗方面我觉得主要还是靠的每年规定的强制体检，遍地小医院（诊所），稍微感到有点不舒服走几步路去看一下非常方便，而且无论看啥医保报销后都最多付 30%，看病经济负担没那么大（分级诊疗的好处之一）。也意味着日本很多病在初期阶段就能筛查出来或者解决掉，并不是完全靠对大病的治疗能力。
比如我在日本几年，稍微感到不舒服就往诊所跑（怕死），手上诊疗卡都一大摞了，很多小病或者不舒服立刻就初期解决掉了，主要经济也没什么负担。

但是相对应的，对于那些医生觉得没大事但自己非常急的病来说，这种分级诊疗就蛋疼了。我之前血检肝脏转氨酶挺高，但我并不胖从不喝酒抽烟，还常年坚持运动，天天吃蔬菜沙拉全麦面包鸡胸肉，结果超声波说我有中度脂肪肝，医生说你这情况还不正常也正常。我觉得不放心想做个核磁，结果分级诊疗下从我希望做核磁到真的到大医院预约到核磁（大医院不会上来就给你核磁，而是先所有检查再做一套然后让你等复查，复查完后再预约一个月后的核磁）。耗时三个月，我最后绷不住了，趁着年底回国直接在国内医院做了增强扫描，前后耗时两天

yysy 小红书一些攻略是真的细
比如换乘，有的攻略他能把你从进站到站台多少分钟，等车多少分，下车出站多少分，事无巨细地写出来

对于坐飞机高铁这类时间卡死需要精细规划的人来说，简直是神。没有哪个地方的攻略会写得这么详细

有公网 ip 我也绝不会直接把任何服务暴露到公网里，反正有没有公网 ip 我回家都是靠 tailscale 组网连回去的没任何区别。

唯一区别就是 tailscale 组网，有公网 ip 不需要费劲打洞之类的。但这种问题我租个服务器自建 relay 就解决了，一年 relay 服务器的价格也就几百块，家用公网 ip 这东西一年超过几百的话我肯定不付钱

fcm 推送是需要用长连接的，你的梯子不支持长连接吧

日本线下怎么会没货，只不过免税店的话没货的概率大点

@wjpauli 明白了，如果你不需要的话那直接把这些不需要的 Cloudwatch Alarms 全删了就行了。
至于这个 DynamoDB 的 ConsumedReadCapacityUnits ，是监测 Dynamodb 获取到的读取单位，低于 30 就告警我不太能想到是怎样的应用场景，这些 Alarms 是怎么生成的我就不知道了。是出于什么目的其他组员添加的还是自动生成不太清楚（至少我做的这么多项目，用 DynamoDB 没有自动给我添加过这些 Alarms 全是手动的）。难道是你学习 DynamoDB 的时候用了什么练习用的 guide 自动给你生成的？

啊这 url 没有复制完整
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/tracking-free-tier-usage.html

@gklll 问题不在大改，在于苹果已经在 MiniLED 和 MicroLED 上投资很多钱了。放弃转投 OLED 我想不到什么好处

@geeksammao 就是 MicroLED ，兄弟。MicroLED 这两年已经开始逐渐量产商用了，目前主要是用在 VR/AR 设备上。比如雷鸟的那个眼镜就是 MicroLED 。至于单色 MicroLED 的话比如 JBD 在 21 年就量产了，比如他家的 0.13 尺寸的单色 MicroLED 、640 * 480 分辨率，450 万尼特亮度，100mW 功耗

MicroLED 已经越来越近了。我觉得再等个最多四五年就会大爆发

OLED 平板这东西是最不明所以的，而且 OLED 平板这东西从几年前就开始看媒体发文，真就只要发的频率够高总有中的那一天是吧

说真的，我觉得苹果智商正常应该不太会出 OLED 平板（出 OLED 的好处我只能想到减少屏幕寿命，增加平板更新换代速度）。现在 MicroLED 都已经开始逐渐投产了，一些产品上都开始用 MicroLED ，苹果还去整那 OLED 是真的蠢，毕竟苹果自己在 MiniLED 和 MicroLED 都投了那么多钱。放弃这条路线想不出有什么好处

lz 对 js promises 和 js 的异步的理解有误。Promise 的异步本质是回调函数，以前 js 没有 Promise 的时候，js 和 Python 这些脚本一样，要实现异步只有用回调函数（ callback function ）来实现，结果就是导致回调地狱的出现。后来为了解决这个问题才有了 Promise ，但 Promise 本质上还是更好用的回调函数，并没有改变任何 js 的底层。然后 async await 是 Promise 的语法糖，async await 的代码看起来像是同步，实际上依旧是同步执行的回调

so ，js 中并不存在语言或者 js 引擎层面的任务排队这个概念，他就是一路同步执行下去的。然后 Peomis 构造函数是立刻执行，所以你在构造函数里做大量计算，这种会一直占用线程的操作的话，后面的操作自然不会去执行了

大法 wf3 wf4 用户路过提醒，千万别买大法的 tws 耳机，千万别买大法的 tws 耳机，千万别买大法的 tws 耳机
重要的话说三遍。我现在看着最新的 wf5 一点买的欲望都没有

@wjpauli 找到了一篇日文文章，看着应该还算靠谱比较新（用翻译软件翻译一下就 ok ）

https://zenn.dev/seapolis/articles/6669b3c1cda5b0#lambda%E3%81%AB%E8%BC%89%E3%81%9B%E3%81%A6%E3%81%BF%E3%82%8B

里面用了 @h4ad/serverless-adapter 做了 lambda handler 和 express 的兼容。deploy 用的是 serverless 框架，但我觉得你要是玩不转 serverless 这个框架，直接手动把最后的文件 bundle 成单一文件 zip 一下，然后手动上传也不是不行。。。。至少能了解下 lambda 的运行方式。然后要么用 cdk 要么 serverless 框架

至于怎么和 cloudfront 结合，也有介绍（直接给 cloudfront 连上 lambda 的 url ，虽然一般用得更多的是 aws apigateway+lambda 再套一层 cloudfront ）

机械硬盘分区的确是能提升性能的，盘外侧转速高性能更好

还有一个就是当年的使用习惯（ ghost 之类的，还有各种当年的电脑报啥的也是推荐分多个区）

你本地怎么跑起来那就打包好扔到 lambda 啊，没必要去专门找部署教程（做 handler 适配倒是需要）

lambda 部署到 aws 建议使用 cloudformation 或 cdk ，后者支持 typescript 你不会陌生。cdk 默认使用 esbuild 做 bundle ，你也可以手动 bundle 然后用 cdk 部署

天国的 Google RSS(Google Reader)

@bluepot 淡定，纯经验积累。当你有长久和这些 CI/CD 平台，云平台斗智斗勇的话，就会有对应的直觉经验了

@NX2023 不依赖太多东西的话用 act 还能凑活用用，但依赖了其他东西（比如各种 key 甚至虚拟化的话）那就不太好用 act 了，这时候就是改一行 push ，改一行 push 这样