unravel2025

让自定义类型支持 for-in：三分钟实现 Sequence 需求 自己写了一个“分页加载器”，想这样用： 实现 要点 只要 makeIterator() 返回的对象能满足 IteratorProto

为什么 Swift 的控制流值得单开一篇？ 语法糖多：区间、stride、tuple、where、guard、defer…… 安全严苛：switch 必须 exhaustive、case 不能空、默认

历史包袱：海量第三方 SDK 仍是回调形态 痛点： 嵌套地狱（Callback Pyramid） 错误处理分散 难以取消 官方桥接器：withCheckedThrowingContinuation 核

@autoclosure：把“表达式”包成“闭包”，实现“短路求值” 场景回顾 问题： 字符串先拼接完成，再传进函数——性能浪费。 若拼接代价高（"计算成本：\(expensive())"），则每次调

泛型函数：让代码从“具体类型”升维到“抽象类型” 场景：写了一个交换两个 Int 的函数，后来又要交换 Double、String、CGPoint…… 泛型版本： 泛型约束：只支持“可比较”类型 多占

函数的本质 自包含的代码片段，完成一个“任务”。 有名字 → 可被重复“调用”。 有类型 → 由“参数类型 + 返回类型”组成，可以像 Int、String 一样被赋值、传递、返回。 可嵌套 → 在函

前言 闭包是 Swift 的“灵魂语法”之一。它同时承担了 函数式编程的高阶函数； 面向对象中的委托回调； 异步并发中的逃逸闭包； 甚至属性包装器与 DSL 的构建基础。 闭包到底是什么？—— 一句话

从零实现一个 CircularArray 需求：固定容量，到达上限后从头覆盖，支持 for-in、count、randomAccess。 步骤： 遵循 Collection 协议； 提供 startI

为什么要“自定义”Hashable？ 官方文档只告诉你“Set/Dictionary 的元素/键必须 Hashable”，却没说： 系统默认的哈希算法什么时候会“翻车”？ 手写 hash(into:)