/tag/What

还好之前能接码的时候闲的没事用Talkatone注册了whatsApp 现在codex能用上了,哈哈哈 1 个帖子 - 1 位参与者 阅读完整话题

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 多账号 / sms注册 / OTP接收 / 消息接收 目前大致这个效果吧，欢迎 PR / issue wa-app 开源地址 5 个帖子 - 4 位参与者 阅读完整话题

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 Github sms注册/OTP/消息接收/多账号 大致这个效果吧，欢迎PR/issue，如果对你有用的话，帮我点个star吧～ 9 个帖子 - 8 位参与者 阅读完整话题

欧盟反垄断监管机构周二发布临时命令，要求美国科技巨头Meta Platforms在调查期间向竞争对手的人工智能聊天机器人免费开放WhatsApp接入权限，以审查该公司是否通过封锁竞争者滥用市场支配地位。 这是欧盟委员会17年来首次对企业祭出反垄断“临时措施”。此前，美国加州互动公司（The Interaction Company，开发Poke.com AI助手）、法国初创企业Agentik以及一家西班牙竞争对手先后向欧委会投诉，指控Meta利用其在消息服务领域的地位排挤对手。 在相关投诉之后，作为欧盟竞争事务执法机构的欧委会于去年12月对Meta启动正式反垄断调查，并于今年2月向该公司发出异议陈述，指其涉嫌违反欧盟反垄断规则。 欧盟竞争事务负责人特蕾莎·里韦拉在声明中表示，在快速演变的市场中，“竞争可能在最终决定作出前很久就已经被扼杀”。她指出，这一临时措施旨在维护新兴AI助手市场的竞争，通过保留WhatsApp这一“触达欧洲消费者的关键入口”，帮助人工智能公司继续创新、扩张并发挥其全部潜力。 Meta则对欧委会的决定提出强烈批评。该公司在一份电邮声明中表示，欧盟委员会的决定意味着，OpenAI以及“世界上一些最大型的公司”将可以免费使用WhatsApp的付费企业服务产品（WhatsApp Business）。 Meta称，这一决定是“由众多付费使用该服务的欧洲企业承担成本的监管越权行为”，并表示将提起上诉。 事件的焦点在于Meta对WhatsApp企业版应用程序接口（API）的访问政策。该接口允许企业将自身系统与WhatsApp连接，用于与客户进行自动化沟通和服务。 去年10月，Meta禁止竞争性AI服务接入WhatsApp Business API，但对自家AI助手“Meta AI”则予以豁免。 今年3月，Meta重新允许竞争对手通过该接口提供服务，但需支付费用，此举随即遭到欧委会的反对。 根据欧盟此次发布的临时命令，Meta必须在五个工作日内，在与去年10月前相同的条款和条件下，恢复竞争对手对WhatsApp Business API的访问权，且不得收取额外费用。 在最终裁决中，如果被认定违反欧盟反垄断法规，Meta最高可能面临相当于其全球年度营业额10%的罚款。 查看评论

我有一个新加坡的手机号和whatsapp，但我如果要接码多个号的话是不是只能选验证码验证，whatsapp是只能接码一个ChatGPT账号的对吗 3 个帖子 - 3 位参与者 阅读完整话题

大佬，刚到GG卡，GPT plus上一波查杀没解封。gg卡是激活吗？还是留着先？还是开通个whateapp？ 9 个帖子 - 7 位参与者 阅读完整话题

有佬知道这个要咋解决吗？ 刚注册的gg卡，一直收不到telegram的验证码 测试了下。whatsapp的是可以正常收到 14 个帖子 - 6 位参与者 阅读完整话题

真机上挂一个whatsapp，之前印尼号接码注册的，貌似也能作为长效接码手段，成本低于gg卡，有什么坑吗。 10 个帖子 - 9 位参与者 阅读完整话题

各位佬友有碰到类似的问题吗 注册苹果账号的时候，显示发送短信了，但是接不到码；WhatsApp是显示这个，并且无法使用电话和挂断验证 我是用的9eSIM v0 收到沃达丰邮件激活之后没有收到激活成功的短信，但是沃达丰APP登录的时候可以收到短信。 注册tg的时候，也无法使用语音通话挂断的方式验证，只能使用验证码 22 个帖子 - 6 位参与者 阅读完整话题

刷到好几个反向保活的帖子赶紧过来问问，佬们说说有必要保活吗？如果要保活 whatsapp 需要注意哪些细节？ 5 个帖子 - 4 位参与者 阅读完整话题

用了一年多的openai账户，今天codex突然要接码，绑的是Talkatone号码，现在接码要开套餐（以前免费），codex可以用whatsapp接码方式，但whatsapp接码可以使用语音通话形式接码，抱着试一下的心态竟然接码成功，成功登录whatsapp，最后codex用whatsapp成功登录。 简单的操作步骤 1、whatsapp通过语音通话形式接受Talkatone验证码完成登录（目前可以正常接受，短信不行，必须开套餐）。 2、codex登录用whatsapp接码 瞬间感觉Talkatone又行了 佬友还有talkatone号码的可以试一下。细想好像接码问题又解决了，动手能力强的佬友们行动起来 1 个帖子 - 1 位参与者 阅读完整话题

我新搞了一个giff号，准备注册whatsApp，在验证时提示我无法给该手机发送短信，这是为什么啊？ 我再次尝试的时候就提示我1小时后再试，现在看24小时后了。 有佬知道为啥吗？ 13 个帖子 - 9 位参与者 阅读完整话题

表现为点击接码后就跳转到要求强制whatsapp接码 各位有没有遇到相似的情况，又是如何解决的 3 个帖子 - 2 位参与者 阅读完整话题

单纯接码codex,一个可以绑定几个有佬知道吗 6 个帖子 - 3 位参与者 阅读完整话题

买了小白卡，通过easyeuicc写入了小白卡后 怎么办 立即注册一个whatsapp账号吗 平时直接在手机SIM卡里关闭它等要用时再打开，还是一直开着？ 9 个帖子 - 6 位参与者 阅读完整话题

大家吼哇，Kotlin 2.4.0 千呼万唤始出来哇！ 老规矩，本次更新内容可以在 JetBrains 官方的 What’s new in Kotlin 2.4.0 查阅， 我照例挑自己比较感兴趣的一些改动聊聊。 剧透 首先总结：这次转正的东西不少，新实验特性也挺有意思，尤其是 context parameters 稳定、集合字面量、标准库 UUID 稳定、以及 Kotlin/JS 导出体验继续改进。 注意！这次依旧是「我个人」的更新摘要，覆盖不了全部改动；如果你对某个方向特别感兴趣，记得继续深入官方文档喔。 文中示例如无特殊说明均来自或改写自官方日志。 语言特性 一如既往，先来看语言层面的更新。这次比较醒目的有两类：一类是之前几个实验特性终于转正了，另一类是又塞进来了一些新玩具。（嗯…一如既往。） 稳定特性 首先是几个稳定下来的特性： context parameters 属性上的 @all meta-target use-site annotation targets 的新默认规则 显式后备字段 context parameters 稳定这件事着实是特大喜事一件那！毕竟这东西从 context receivers 一路改到 context parameters ， 中间变来变去也折腾了不少版本（也让我折腾了半天编译器插件），现在终于算是可以比较放心地在正式代码里试着用起来了。芜湖！ 不过要注意， context parameters 的「显式 context arguments」和「callable references」还不在这次稳定范围里。也就是说，主干能力稳定了，但边边角角还在继续打磨。 @all 和 use-site annotation targets 的默认规则稳定也挺实用，尤其是你写一些跟 Java 框架互操作的代码时， 以前各种 @field: 、 @param: 、 @get: 多个重复的内容写起来还是挺烦的。 显式后备字段也稳定了，这个我在 2.3.0 的时候就提过： val city: StateFlow<String> field = MutableStateFlow("") fun updateCity(newCity: String) { city.value = newCity } 以前常见的 _city + city 两个属性组合，在一些场景下可以被简化掉了。好用，爱用。 显式 context arguments 书接上文。2.3.20 修改了 context parameters 的重载解析规则之后，如果两个重载只差 context 参数， 有些调用会变成歧义。现在 Kotlin 2.4.0 给出了一个新的实验性解法：显式传递 context argument。 比如官方给的例子大概是这样： class EmailSender class SmsSender context(emailSender: EmailSender) fun sendNotification() { println("Sent email notification") } context(smsSender: SmsSender) fun sendNotification() { println("Sent SMS notification") } context(defaultEmailSender: EmailSender, defaultSmsSender: SmsSender) fun notifyUser() { sendNotification(emailSender = defaultEmailSender) sendNotification(smsSender = defaultSmsSender) } 这样就可以在调用点明确告诉编译器：我要的就是这个 context 参数对应的重载。 我觉得这功能属于“你平时不一定用，但一旦遇到歧义就很救命”的东西。 尤其对 DSL 或者库作者来说，这至少比通过改函数名、改参数列表来绕开歧义要优雅不少。 语法上来讲，把这东西直接作为具名参数的一员也算符合 context parameters 中的这个 parameters 。 目前它还是 实验性的 ，需要添加编译器参数： kotlin { compilerOptions { freeCompilerArgs.add("-Xexplicit-context-arguments") } } 集合字面量 哦豁，集合字面量来了！ 这下代码量又得降上个 30% 了。 现在可以用方括号 [] 来创建集合： fun main() { val shapes: MutableList<String> = ["triangle", "square", "circle"] println(shapes) // [triangle, square, circle] } 如果编译器没有足够的类型信息，它会默认推断为 List ： fun main() { val fruit = ["apple", "banana", "cherry"] println(fruit) // [apple, banana, cherry] } 这东西乍一看很像“终于补上了别的语言早就有的语法糖”，但是！Kotlin 的设计里还塞了一个更有意思的点： 可以通过 operator fun of 给自定义类型提供字面量构造能力。 比如： class DoubleMatrix(vararg val rows: Row) { companion object { operator fun of(vararg rows: Row) = DoubleMatrix(*rows) } class Row(vararg val elements: Double) { companion object { operator fun of(vararg elements: Double) = Row(*elements) } } } 然后就可以这样写： fun main() { val identityMatrix: DoubleMatrix = [ [1.0, 0.0, 0.0], [0.0, 1.0, 0.0], [0.0, 0.0, 1.0], ] } 这就有点意思了。对于矩阵、向量、DSL 配置、甚至一些查询条件构造来说，应该都能玩出花来。 能有多少花活儿就…任君想象了~ 不过它目前还是 实验性的 ，而且目前不能用来构造 Java 中定义的集合类型。 启用方式如下： kotlin { compilerOptions { freeCompilerArgs.add("-Xcollection-literals") } } 改进编译期常量 Kotlin 2.4.0 还对编译期常量做了一些实验性增强，包括： 支持无符号类型操作。 支持一些字符串标准库函数，比如 .lowercase() 、 .uppercase() 、 .trim() 。 支持计算枚举常量和 KCallable 的 .name 属性。 举个感觉上可能会更直观的例子： const val NAME = " Forte ".trim().uppercase() 当然，上面这个只是为了说明用途，具体哪些函数能在编译期求值，还是要以官方支持列表为准。 它们还引入了一个 IntrinsicConstEvaluation 注解，用来标记哪些函数可以被编译期求值。 有一说一，这些东西真到需要的时候是相当有用的，尤其是无符号类型的常量和字符串常量的函数。 这个特性目前也还是 实验性的 ： kotlin { compilerOptions { freeCompilerArgs.add("-XIntrinsic-const-evaluation") } } 改进未使用返回值检查器 之前 2.3.0 里提过 -Xreturn-value-checker ，这次又往前推了一步： 新增了一个实验性的 returnsResultOf() contract。 它的主要作用是帮助检查器分清楚：一个高阶函数返回的结果，到底是不是来自传入的 lambda。 比如： import kotlin.contracts.ExperimentalContracts import kotlin.contracts.contract @OptIn(ExperimentalContracts::class) inline fun <T, R> T.customLet(block: (T) -> R): R { contract { returnsResultOf(block) } return block(this) } 这样检查器就可以更准确地判断下面这种情况： fun handleNullablePackageName(packageName: String?, builder: StringBuilder) { packageName?.customLet { builder.append(it) } // 这里返回了一个 String，但结果没被使用，检查器可以报告 warning packageName?.customLet { "kotlin.$it" } } 对于写 DSL 或者工具库的人来说，这个方向其实挺重要的。Kotlin 的表达式和作用域函数太好用了， 但也确实容易写出“以为自己返回了，实际上把结果丢了”的代码。 虽然这里面有一部分也算是使用者没有仔细了解 API 的锅，但是作为作者，多一些防备和提醒终归是好的。 启用参数如下： kotlin { compilerOptions { freeCompilerArgs.add("-Xallow-returns-result-of") } } @IntroducedAt 这个我觉得对库作者很有价值。 Kotlin 2.4.0 新增了实验性的 @IntroducedAt 注解，用来在给已发布 API 添加新的可选参数时，保留二进制兼容性。 过去你给一个函数加默认参数，老版本调用方可能就炸了。你要么手写隐藏的兼容 overload， 要么上 @JvmOverloads ，但它又可能生成一堆你不一定需要的重载。 现在可以这么写： @OptIn(ExperimentalVersionOverloading::class) fun Button( label: String = "", color: Color = DefaultColor, @IntroducedAt("1.1") borderColor: Color = DefaultBorderColor, @IntroducedAt("1.2") borderStyle: Style = DefaultBorderStyle, @IntroducedAt("1.2") borderWidth: Int = 1, onClick: () -> Unit ) { // Function body } 编译器会根据这些版本信息生成对应的隐藏 overload。 这对 Compose 风格 API 或者一些公共 DSL 来说应该蛮有用。 毕竟这种 API 往往会不断加参数，而且又不想每加一次参数就让用户老版本二进制出问题。 兼容性的老大难问题一下子简化了不少，妈妈再也不怕我为了检查 ABI 兼容性而掉光头发了！ 标准库 标准库这次也挺有内容的，其中我比较关注的是 UUID 稳定、排序检查，以及 nullable map 的 fallback API。 UUID API 稳定 Kotlin 2.0.20 引入的 common UUID API 终于稳定啦！ 之前陆陆续续加过 UUID 解析、格式转换、和 Java UUID 互转之类的能力。到了 2.4.0， 除了生成 v4 和 v7 UUID 的那几个函数仍然是实验性的以外，其他大部分 UUID API 都稳定了。 这意味着你终于可以在公共 API 里更放心地使用 kotlin.uuid.Uuid 了。 好耶，多平台项目里又少一个自己糊类型或者引第三方库的问题。 检查是否已排序 标准库新增了一组检查集合、数组、序列是否有序的扩展函数： .isSorted() .isSortedDescending() .isSortedWith(comparator) .isSortedBy(selector) .isSortedByDescending(selector) 例如： data class User(val name: String, val age: Int) fun main() { val numbers = listOf(1, 2, 3, 4) println(numbers.isSorted()) // true val users = listOf( User("Alice", 24), User("Bob", 31), User("Charlie", 29), ) println(users.isSortedBy(User::age)) // false } 一个很朴素，但是实用的 API。 无符号整数转 BigInteger Kotlin/JVM 现在给 UInt 和 ULong 加了 .toBigInteger() ： fun main() { val unsignedLong = Long.MAX_VALUE.toULong() + 1uL val unsignedInt = UInt.MAX_VALUE println(unsignedLong.toBigInteger()) // 9223372036854775808 println(unsignedInt.toBigInteger()) // 4294967295 } Kotlin: 顺手的事儿。 nullable map 的 fallback API 2.4.0 给 value 可空的 Map 增加了几组实验性的 fallback 函数，用来区分： 这个 key 是不存在，还是存在但值就是 null 。 新增的函数主要有： .getOrElseIfNull(key, defaultValue) / .getOrPutIfNull(key, defaultValue) .getOrElseIfMissing(key, defaultValue) / .getOrPutIfMissing(key, defaultValue) 来看区别： @OptIn(ExperimentalStdlibApi::class) fun main() { val mapForNull = mutableMapOf<String, String?>("user" to null) val mapForMissing = mutableMapOf<String, String?>("user" to null) mapForNull.getOrPutIfNull("user") { "default_user" } println(mapForNull) // {user=default_user} mapForMissing.getOrPutIfMissing("user") { "default_user" } println(mapForMissing) // {user=null} } 这对缓存场景尤其有用。比如你缓存一个查询结果，而“查到了，但是结果为空”本身也是一个有效缓存， 那你就不希望下次又重新查一遍。 @OptIn(ExperimentalStdlibApi::class) fun getCachedResponseOrQuery(key: String): Response? = cache.getOrPutIfMissing(key) { service.query(key) } 以前这种语义经常要自己写 containsKey 判断，现在标准库终于给了更明确的 API。 NULL safe 语言一定要对 NULL 的处理精准而全面！ Kotlin/JVM JVM 这边这次内容不算多，但是有两个点。 支持 Java 26 Kotlin 2.4.0 开始支持生成 Java 26 字节码。 我现在主要还是稳定在用 Java21/25，对于非 LTS 版本还是涉猎比较少。 metadata 中默认写入注解 Kotlin 2.2.0 的时候，Kotlin Metadata JVM library 支持读取 metadata 中的注解。 到了 2.4.0，这个支持默认开启了。 也就是说，编译器会把注解信息写入 Kotlin metadata，注解处理器和其他工具可以在 metadata 层面读取这些内容， 而不必依赖反射或者源代码。 这对框架、代码生成、静态分析工具来说应该很有用。 我猜未来很多 Kotlin 原生工具链都会逐渐更依赖 metadata，而不是硬往 Java 反射模型里塞。 Kotlin/Native Native 这次依旧是工程向、Apple 向、Swift 互操作向的更新。我对这块不算熟，所以主要挑几个我看得懂 （或者至少能假装看得懂） 的点。 CMS GC 默认启用 Kotlin/Native 的 concurrent mark and sweep garbage collector，也就是 CMS GC，现在默认启用了。 过去默认的 PMCS 在标记阶段需要暂停应用线程，而 CMS 可以让标记阶段和应用线程并发执行。 官方说这会显著改善 GC pause 和应用响应性，尤其对 Compose Multiplatform 这类 UI 应用有帮助。 如果遇到问题，也可以在 gradle.properties 里切回旧模式： kotlin.native.binary.gc=pmcs GC 也是一个需要长期演进的艰难课题哇。 Swift export 进入 Alpha Swift export 终于进入 Alpha 了，而且这次重点改善了并发支持。 现在 Kotlin 的 suspend 函数可以更自然地导出成 Swift 的 async ： suspend fun hello(): String { delay(1000) return "Hello Swift! This is Kotlin." } Swift 侧： let msg = try await hello() 另外， kotlinx.coroutines.flow.Flow 也可以导出成 Swift 的 AsyncSequence 。 这点我觉得挺关键的，因为移动端跨平台里，异步流式数据几乎绕不开。 还记得上次对 .d.ts 的导出支持 suspend 吗？这次 swift 也享受到了。 Swift package import KMP 项目现在可以在 Gradle 配置里声明 Swift Package 作为 iOS app 的依赖： kotlin { swiftPMDependencies { swiftPackage( url = url("https://github.com/firebase/firebase-ios-sdk.git"), version = from("12.11.0"), products = listOf( product("FirebaseAI"), product("FirebaseAnalytics"), ) ) } } 如果你以前用 CocoaPods，官方也提供了迁移到 SwiftPM 的文档和工具支持。 这类更新就很明显了：KMP 在 iOS 生态里继续往“别那么别扭”的方向推进。 Apple 目标支持变化 Kotlin 2.4.0 提升了 Apple 目标的默认最低支持版本： iOS / tvOS 从 14.0 提升到 15.0 macOS 从 11.0 提升到 12.0 watchOS 从 7.0 提升到 8.0 如果你需要支持更低版本，可以通过编译器参数覆盖。 时代在前进，老设备在落泪。 我的 intel mac 还能战斗到什么时候？ Kotlin/Wasm Wasm 这次我觉得有两个重点：增量编译默认启用，以及 WebAssembly Component Model 的实验性支持。 增量编译默认启用 Kotlin/Wasm 的增量编译从 2.1.0 开始引入，到 2.4.0 稳定并默认启用。 这意味着修改代码后，编译器只需要重编受影响的文件，构建速度会更友好一些。 如果遇到问题，可以关闭： kotlin.incremental.wasm=false K/Wasm 现在最大的问题之一就是开发体验还需要继续打磨，增量编译默认开肯定是好事。 支持 WebAssembly Component Model Kotlin/Wasm 现在实验性支持 WebAssembly Component Model。 简单来说，它定义了一套用标准接口和类型组合 Wasm 组件的方式，让 Wasm 不只是一个低层二进制格式， 而是更像一个可以跨语言复用和组合的组件系统。 这也意味着 Kotlin/Wasm 不只是“跑在浏览器里”，还可以更自然地探索 serverless、FaaS 之类的场景。 官方还给了一个 wasi:http 的示例项目。这个方向我挺期待，虽然目前对大多数业务项目来说还偏早。 有机会找个小项目体验一把。 Kotlin/JS Kotlin/JS 这次继续围绕 JavaScript / TypeScript 导出体验做改进。说实话，这几次更新下来， K/JS 的互操作正在一点点从“能用”往“像个正经 TS 生态公民”靠近。当然，能靠多近就要看 jb 有多努力了。 支持导出 value class 之前只有普通 Kotlin 类能导出到 JavaScript / TypeScript。 现在 Kotlin 2.4.0 支持导出 inline value class 了。 例如： @JsExport @JvmInline value class Email(val address: String) { init { require(address.contains("@")) { "Invalid email" } } } @JsExport class AuthService { suspend fun login(email: Email): String = TODO() } TS 侧会像普通类一样使用： import { AuthService, Email } from "..." const auth = new AuthService() console.log(await auth.login(new Email("[email protected]"))) value class 本来就是 Kotlin 里很适合做强类型包装的东西， 如果导出到 TS 时不能保留这种模型，就会很影响 API 设计。不赖！ inline JS 支持 ES2015 Kotlin 2.4.0 的 js() 内联代码现在完整支持 ES2015 特性，比如： const / let class generator arrow function spread / rest operator template string 比如： fun spreadExample(): dynamic = js(""" const add = (a, b, c) => a + b + c; const nums = [1, 2, 3]; const sum = add(...nums); return { sum }; """) 这个对需要跟第三方 JS 库做细颗粒度互操作的人来说，还是挺舒服的。 毕竟 2026 年了，在内联 JS 里还不能好好写现代 JS 确实有点说不过去。 不过我本人在 js(“…”) 里写大段 JS 片段的情况还算比较少，所以之前也没怎么体会到问题所在。 导出 TypeScript 时保留型变 以前 Kotlin 泛型里的 in / out 信息导出到 TypeScript 时会丢掉。 现在它会被保留并映射到 TypeScript 的 variance annotations。 例如 Kotlin： interface Producer<out T> { fun produce(): T } interface Consumer<in T> { fun consume(item: T) } 生成的 .d.ts 会保留： export interface Producer<out T> { produce(): T; } export interface Consumer<in T> { consume(item: T): void; } 类型系统信息少丢一点，互操作就少一点坑。 改进接口导出 新的 @JsNoRuntime 注解可以让 Kotlin 接口导出成更普通的 TypeScript interface， 不再携带之前那些为了 Kotlin runtime 识别接口所需的 metadata。 例如： import kotlin.js.JsNoRuntime @JsNoRuntime expect interface DataProcessor { fun process(data: String): Int } 生成出来就是： export interface DataProcessor { process(data: string): void; } 当然代价也很明确：标记了 @JsNoRuntime 之后，就不能再对这个接口做 is / as 检查、 ::class 引用， 也不能作为 reified 类型参数传来传去。 这就是一个取舍：如果你想要更像 TypeScript 原生接口，那就别指望它还保留 Kotlin runtime 的那些能力。 另外，这次还放宽了 @JsExport 导出接口的限制，现在可以导出带嵌套类和命名伴生对象的接口了。 Gradle & Maven 构建工具这块简单看一下。什么，还有 Maven 的事儿？ Gradle 方面，Kotlin 2.4.0 兼容 Gradle 7.6.3 到 9.5.0 ，最低支持的 Android Gradle Plugin 提升到了 8.5.2 。 另外，默认 module name 在各平台之间统一为 {group}:{project_name} ，减少跨平台命名不一致带来的冲突。 如果你想回到旧的 JVM module name，可以手动配置： kotlin { compilerOptions.moduleName(project.name) } Maven 方面，这次做了两个比较实用的改进： Kotlin Maven 插件可以自动对齐 Java compiler version 和 Kotlin JVM target。 支持 Maven Toolchains，用来统一控制 Kotlin 编译使用的 JDK。 虽然我个人还是选择 Gradle，但 Maven 用户看到这个应该会舒服不少。 编译器、插件和 Compose klib 编译时同模块 inline 行为更一致 Kotlin/Native、Kotlin/JS、Kotlin/Wasm 现在在生成 .klib 时，会默认对同模块内的 inline 函数进行 inline。 这一步是在向 JVM 的行为靠拢，让不同平台对 inline 的兼容性保证更一致。 如果遇到问题，可以用： -Xklib-ir-inliner=disabled 未来还计划继续推进跨模块 inline。 OS: 什么，原来之前不会 inline 的吗？ kapt 可以排除 compile classpath 上的注解处理器 kapt 现在支持 includeCompileClasspath 配置，可以排除不必要的 annotation processor discovery。 Maven 里可以这样配： <properties> <kapt.include.compile.classpath>false</kapt.include.compile.classpath> </properties> Power-assert 新 runtime library Power-assert 这次引入了新的 runtime library。 新的 @PowerAssert 注解可以让断言函数更容易被编译器插件发现， CallExplanation 也能提供更详细的调用点信息。 如果你喜欢写测试，或者想给自己的断言库接入 Power-assert，这个方向值得关注。但是我用的不多，就不过多评价了。 Compose 编译器 Compose compiler 这次主要是让 internal declaration 的增量编译更一致。 不过副作用是：当 @Composable 函数使用来自其他文件的 internal 类型作为参数时，产物体积可能会变大。 官方说 R8 这类全程序优化工具可以消掉这部分额外开销。 此外，一些已经稳定或准备淘汰的 feature flag 也进入新的弃用阶段： StrongSkipping 、 IntrinsicRemember 相关 DSL 提升到 DeprecationLevel.ERROR ，计划 2.5.0 移除。 OptimizeNonSkippingGroups 、 PausableComposition 已弃用，计划 2.6.0 移除。 破坏性变更和弃用 这次有几个需要注意的兼容性点： Kotlin 2.4.0 不再支持 -language-version=1.9 ，也就是说 K1 编译器正式不再支持。（我的编译器插件终于不用再继续兼容旧编译器了 ） Kotlin Gradle Plugin 的 binary compatibility validation DSL 做了精简并弃用了一些旧配置。 Maven 插件里的 KotlinScriptMojo 脚本执行支持被移除了。 如果你的项目还卡在比较老的语言版本，或者构建脚本里有一堆祖传 Kotlin 配置，这次升级前最好扫一眼官方 compatibility guide。 其他 官方这次还更新了一堆文档，比如 KMP、SwiftPM 迁移、Compose Multiplatform、Ktor、KSP、Lincheck、Kotlin LSP 等内容。 如果你最近正好在折腾这些生态工具，不妨顺手去翻翻。 文档，多多益善！ 尾声 这次 Kotlin 2.4.0 给我的感觉是：语言层面继续补语法糖和工具能力，多平台方向继续推进工程化和互操作体验。 context parameters 稳定和集合字面量我是已经期待了很久了，这次也是相当满足。 而那个用于兼容性的 @IntroducedAt 则是一个意外之喜，真是令我欢喜！这个要是能支持到 data class 上就更好了，抽空得狠狠体验一把了。 你呢？这次 2.4.0 里有没有哪个新玩意儿让你眼前一亮？ 2 个帖子 - 2 位参与者 阅读完整话题

之前买的长效美区号看起来好像不能用了，这个号是不是废了 7 个帖子 - 5 位参与者 阅读完整话题

好消息！！！codex不用手机接码了。改用WhatsApp了，第一次可以定可以用手机号码，但是以后验证要用WhatsApp 10 个帖子 - 8 位参与者 阅读完整话题

那个佬 试下talkatone 注册whats 是否可行 不开1刀 接语音验证码 过wh，登入后wh，在用talkatone，手机号 选择 whats 过验证 whatsapp 是否收到验证码 1 个帖子 - 1 位参与者 阅读完整话题

最近被 codex 短信验证吓到了，已经离不开，所以提前购入esim 卡，注册 whatsapp 和电报验证码秒收，终于放心了 20 个帖子 - 10 位参与者 阅读完整话题