@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 这样

给 console.log 套一层，输出时带上时间戳（精确点），感觉可能是 log 输出后的延迟之类的

@fallshuang 这是对的，管理云基本要求至少应该用代码管理基础设施的资源(不过用代码管理往往会陷入资源依赖地狱中，也算是一个缺点了）。不过 cloudformation 我两年前开始就不太用了，主要是这玩意真不适合人类，对复杂的系统写 cloudformation 写到后来我自己都不知道在写什么。现在用得更多的还是 aws 官方的 CDK ，自动编译成 cloudformation 。但是哪怕是 cloudformation/cdk 用多了也是会遇见鬼的，比如最近才发现特么 cloudformation/cdk 竟然不能管理 cloudwatch alarm 的资源 tag 。官方的 issues 挂了好几年地下一堆人崔都不打算做这个功能无语，额外再用 aws sdk 或 cli 去打 tag
反正用了多年 aws ，我对 aws 的态度已经从最开始的“好厉害，好强大”，变成了现在的“你小子又作妖了”了

@fallshuang 其实我觉得以 aws 功能的复杂度，广度，各个服务十几年来迭代出的新旧功能，再加上 aws 功能时不时会隐藏有大坑以及各种隐藏 bug ，这世上应该不存在所谓“精通 AWS”的人。哪怕是我们公司长年为大部分项目提供 aws 设计咨询的专家，该不清楚的方依旧是不清楚的

看了这个帖子才知道原来运维岗位就是干这类工作的，而我一直以来除了写代码还全包了公司项目的项目设计，aws 基础设施设计，运维部署优化，CI/CD 一条龙之类的所有工作 orz 。看来全栈风的公司呆久了至少今后还能换运维岗。。。

windows 用 wsl2+wslg ，创建好环境后把 vhdx 复制出来就能到处用了