Java数组与集合认证考点：HashMap树化与ArrayList扩容复盘-北京尧图网络

公司内部的技术能力测评历来有个反直觉的规律真正拉开分数的往往不是那些看着唬人的框架原理题而是数组和集合这种每天在用、从没认真想过的地基知识。我前后参与过两轮 Java 方向的专业力认证第一轮就栽在一道关于 HashMap 的判断题上——题目给了初始容量和待插入元素个数问会不会触发树化我当时凭印象答了会错得很干净因为漏掉了table 数组长度必须达到 64这个前置条件。那之后我把 Java 数组与集合这两块从头翻了一遍第二轮才把分数提上来。这篇内容就是那次复盘的结果讲这类认证考什么、背后对应哪些源码事实、哪些地方最容易翻车以及怎么把这些考点顺手变成写代码时的肌肉记忆。不管你是准备应试还是单纯想把 Java 基础补扎实下面这些应该都用得上。1. 这类认证考什么数组与集合在能力测评里的真实权重1.1 出题人偏爱的四类题型翻过几套真题卷子你会发现出题思路其实高度收敛基本就四种套路。第一类是概念辨析比如ArrayList 和 LinkedList 谁更适合频繁插入看着像送分题实际上四个选项里往往有两个在特定条件下都成立考的是你有没有想过插入位置在头部还是中间数据量有多大这些前提。第二类是源码细节典型问法是ArrayList 无参构造后第一次 add 时容量是多少答案是 10但如果你答构造时就是 10就错了JDK 8 里构造阶段拿到的是共享的空数组扩容发生在第一次写入。第三类是行为预测给一段代码问输出什么、抛不抛异常比如在 for-each 里 remove 元素。第四类是工程选型给一个业务场景让你挑容器这类题没有标准答案但评分点在于你能不能说清取舍理由。这四类题的难度是递增的。前两类靠背书和看源码能拿下后两类必须真的写过、踩过才答得稳。我在第二轮备考时把重心全放在了第三、四类上因为前两类属于投入产出比高但天花板低的部分大家都背得会拉不开差距。1.2 为什么这两块内容天然是分水岭道理不复杂。数组是 Java 里唯一一种语言级的聚合结构它的行为由 JVM 规范直接定义跟任何类库无关集合框架则是 JDK 用纯 Java 代码搭出来的一整套抽象从接口分层到具体实现的每一层优化都写着设计者的取舍。前者考的是你对语言底层的理解是否精确后者考的是你对数据结构与工程权衡的认知深度。这两样东西恰好是培训班出来和真的写过项目之间最容易暴露差距的地方。我见过不少工作两三年的开发者写业务代码时 List、Map 用得飞快但一问HashMap的默认负载因子为什么是 0.75、为什么容量一定是 2 的幂就答不上来。这不是能力问题是从来没人逼着他们往下挖一层。认证考试的价值就在这里——它用一种不太舒服的方式把你从 API 调用者的舒适区拽出来。1.3 我自己排的复习顺序顺序这事很关键排错了会反复返工。我的做法是数组 → List → Map → Set → 工具类 → 并发容器。先把数组吃透因为集合的底层存储、扩容拷贝、toArray转换全都建立在数组之上再攻 List因为ArrayList的扩容逻辑是理解容量这个概念的最佳样本然后才是 MapHashMap一拿下HashSet就是顺带的它内部就是一个HashMapvalue 是共享的常量对象工具类放后面因为Arrays和Collections里大量方法的行为依赖于前面几块的理解并发容器放最后属于加分项考得不多但答出来很显功底。这个顺序我用下来感觉最顺手因为它符合从具体到抽象、从单线程到并发的认知梯度不会出现学着后面忘了前面的情况。2. 数组三分钟学完语法三年踩不完的坑2.1 定长这个约束决定了后面所有行为数组最本质的特征只有一个长度在创建那一刻就固定了之后永远不变。这一个约束推导出了后面几乎所有考点。因为长度不可变所以扩容这件事在数组层面根本不存在你只能新建一个更大的数组再把旧数据拷过去——ArrayList的grow()干的正是这件事Arrays.copyOf()干的也是这件事。因为长度不可变所以数组没有任何add、remove方法所有增删在数组语境下都是覆盖或搬运。还有几个容易被忽略的事实数组是对象继承自Object所以你可以对它调用getClass()、hashCode()、clone()数组的长度是字段length而不是方法length()字符串才是方法这一点在笔试填空题里被坑过的人不在少数数组创建后元素有默认值int是 0、boolean是false、char是\u0000、引用类型是null这个默认值规则和成员变量一致但和局部变量必须显式初始化完全不同。类型默认值备注byte / short / int / long0数值零值float / double0.0注意是 0.0 不是 0char\u0000打印出来是不可见字符不是空格booleanfalse只有两个值引用类型null包括 String、数组本身另一个高频点是数组协变。String[]是Object[]的子类型所以Object[] arr new String[3];这行代码能编译通过。但如果你往里塞一个Integer编译期也不报错运行时直接抛ArrayStoreException。这是 Java 数组设计上的一个历史遗留问题为了早期泛型缺失时能用而泛型恰恰相反是不变的ListString不是ListObject的子类型这行代码根本编译不过。这个数组协变、泛型不变的对比几乎每套卷子都会出现。2.2 二维数组不是矩阵是数组的数组很多人脑子里把int[][]想成一个矩形表格这个心智模型会在关键时刻骗你。Java 的二维数组本质是一维数组每个元素又是一个一维数组的引用。所以int[][] a new int[3][4]是先创建一个长度 3 的数组再分别为三个位置各创建一个长度 4 的数组。而int[][] b new int[3][];同样合法此时外层数组有 3 个 null 槽位每行需要你单独new。这就引出了不规则数组的概念每一行的长度可以不一样。int[][] ragged new int[3][]; ragged[0] new int[]{1}; ragged[1] new int[]{2, 3}; ragged[2] new int[]{4, 5, 6};如果你按矩形的思维去写ragged[0][2]运行时会抛ArrayIndexOutOfBoundsException。而ragged.length拿到的是 3行数ragged[0].length拿到的是 1第一行的列数这两个值在不规则数组里没有任何固定关系。考试里常见的陷阱题是让你遍历一个不规则二维数组却用a[0].length当列数上限第二行开始就越界了。顺带说一个性能相关的点因为是数组的数组内存上每一行是独立分配的对象在堆上并不保证连续。所以对二维数组做整体遍历时按行遍历外层行、内层列比按列遍历缓存友好得多这个差异在数据量大时非常明显属于典型的能跑和跑得快的区别。2.3 Arrays 里那几个名字像、行为不像的方法java.util.Arrays是个宝藏工具类但里面几个方法的行为差异极大考试爱考实际开发中也爱出错。先说Arrays.asList()。它返回的不是java.util.ArrayList而是Arrays的一个私有静态内部类叫Arrays$ArrayList。这个类继承AbstractList内部直接持有传进来的数组引用所以它是定长的调用add、remove、clear会抛UnsupportedOperationException但set可以正常用因为它只是改数组元素。更隐蔽的坑是它和原数组共享同一份存储你改数组List 里的值跟着变反过来也一样。还有一个经典事故是传基本类型数组进去Arrays.asList(new int[]{1,2,3})得到的不是三个元素的 List而是一个只含一个元素的 List那个元素就是整个int[]因为泛型只能接引用类型int[]被当成了一个Object。要用包装类型数组才符合预期。再说Arrays.sort()。它对基本类型数组用的是双轴快速排序Dual-Pivot Quicksort不稳定对对象数组用的是 TimSort稳定。这个差异是故意的基本类型没有相等但不同的概念稳定性没意义用快排更快对象类型排序时相同的 key 保持原有相对顺序往往有业务含义所以要稳定。考试里如果问排序后相等元素的顺序会不会变你得先看数组是什么类型。Arrays.binarySearch()有个硬性前提数组必须已经升序排好否则结果未定义注意是未定义不是返回 -1。它的返回值也很有特点找到了返回索引没找到返回-(插入点) - 1这个设计是为了让你能通过-(返回值) - 1直接算出应该插入的位置同时保证找不到时返回值一定是负数不会和索引 0 混淆。Arrays.copyOf和System.arraycopy也常被拿来对比。前者返回一个新数组长度可以比原数组长多出来的位置填默认值或短截断底层其实调用的就是后者后者是把源数组的一段拷到已存在的目标数组的指定位置返回 void。要扩容或缩容用copyOf要在已有的大数组里填充一段用arraycopy。2.4 可变参数与数组之间那层隐式转换Object...这种写法编译器会给你转成Object[]所以本质上它就是个数组这也意味着两件事。第一方法签名里foo(String[] arr)和foo(String... arr)是同一个方法不能重载。第二传参时的行为有微妙差异。public static void demo(Object... args) { System.out.println(args.length); } demo(1, 2, 3); // 3自动装箱成 Integer[] demo(new Integer[]{1, 2}); // 2直接当作数组 demo(new int[]{1, 2}); // 1整个 int[] 被当成一个 Object最后一行是很多人想不到的int[]是引用类型是Object的子类所以它作为一个整体被塞进了Object[]里长度自然是 1。这个坑在日志框架、String.format一类的 API 里都真实出现过。解决办法要么显式装箱成Integer[]要么别用基本类型数组接可变参数。另外可变参数如果传null会有一个警告级的歧义demo(null)到底是传一个 null 元素还是传一个 null 数组编译器只能提示你加类型转换。这个细节在代码审查里经常被指出来。3. 集合框架先认清分层再谈选型3.1 Collection 与 Map 是两条互不相交的血脉初学者容易把Map当成Collection的一种这是错的。JDK 里Collection和Map是两个完全独立的顶层接口没有任何继承关系。之所以看起来像一家人是因为Map的keySet()、values()、entrySet()返回的视图都是Collection的子类型。Collection下面分三支List有序、可重复、有索引、Set不重复HashSet无序、LinkedHashSet保插入序、TreeSet保排序、Queue/Deque队列语义ArrayDeque做栈比Stack更好因为Stack继承自Vector所有方法都加了同步单线程下纯属浪费。Map则独立成树HashMap、LinkedHashMap、TreeMap、Hashtable、ConcurrentHashMap各自解决不同问题。搞清楚这个分层之后很多题目就好答了。比如问HashSet怎么保证元素不重复答案不在HashSet里——它内部就一个HashMapadd(e)实际是map.put(e, PRESENT)靠HashMap的 key 唯一性实现。再问LinkedHashMap怎么保持顺序它继承HashMap只是在节点上加了before/after两个指针串成双向链表插入时维护链表即可而且构造参数accessOrdertrue时每次get也会把节点挪到链表尾部这就是一个现成的 LRU 骨架。3.2 ArrayList 的扩容曲线与 fail-fast 的真实边界ArrayList的容量增长是 1.5 倍源码里就一行int newCapacity oldCapacity (oldCapacity 1);。用位移代替除以 2是早期 JVM 上的一点微优化现在 JIT 早就把这个差异抹平了但代码保留了下来。为什么选 1.5 而不是 2因为 2 倍增长在多次扩容后空间浪费会累积得很快1.5 倍在拷贝次数和空间浪费之间取了个折中还能让释放的旧空间有机会被后续分配复用。JDK 8 里有个容易被忽略的细节无参构造时elementData被赋值为共享的空数组DEFAULTCAPACITY_EMPTY_ELEMENTDATA真正的 10 容量是在第一次add时才分配的。这个懒初始化设计是为了省内存——大量创建却从不写入的空列表不再各占一个 10 元素数组。所以new ArrayList()之后容量是多少这个问题严格答案是0第一次添加后变 10。modCount与ConcurrentModificationException这对组合也是必考点。ArrayList内部维护一个修改计数器每次结构性修改增、删都会modCount迭代器创建时把当前值存进expectedModCount每次next()前检查两者是否相等不等就抛异常。这里有两个关键认知一是fail-fast 是尽力而为的检测机制不保证一定触发规范里明说了它只能用来发现 bug不能用来做并发正确性保障二是只有迭代器自己的remove()/add()会同步更新expectedModCount直接调集合的remove()不会所以前者安全、后者抛异常。3.3 LinkedList 的性能传说得靠实测戳破频繁插入删除用LinkedList这句话几乎是 Java 圈的都市传说但它的成立条件窄得惊人。LinkedList是双向链表插入删除本身确实是 O(1)可问题在于你得先找到那个位置。add(int index, E e)内部会调用node(index)定位节点虽然用了折半查找索引小于一半从头找否则从尾找复杂度仍然是 O(n)。我做过一个简单的对照实验往头部、中部、尾部分别插入 10 万条数据操作位置ArrayList 耗时相对值LinkedList 耗时相对值头部插入极慢每次全量搬移快中部随机插入慢慢定位成本占主导尾部追加快均摊 O(1)快随机 get(i)快O(1)极慢O(n)结论很清楚LinkedList只在头部插入和已有迭代器位置上的插入删除这两个场景有优势其余情况几乎全面落后。再加上每个节点要多维护两个引用、对象头开销也大内存占用可能是ArrayList的两三倍而且链表节点在堆上分散缓存命中率极差。所以在实际项目里我基本只在需要Deque语义当队列或栈用时才选它ArrayDeque反而是更常见的首选。3.4 HashMap 的扰动、扩容与树化三重门HashMap是集合部分考得最深的一块得拆成三层看。第一层是哈希扰动。put时不是直接拿key.hashCode()当哈希值而是走了一步h key.hashCode(); h ^ (h 16);把高 16 位异或到低 16 位上。为什么要多这一步因为定位桶用的是(n - 1) hash当数组长度不大时比如 16n-1是 0b1111只有哈希值的低 4 位参与运算高位完全浪费。扰动之后高位信息被折叠进低位哈希分布更均匀冲突率明显下降。第二层是扩容。默认容量 16、负载因子 0.75、阈值 12这三个数字要一起记。容量必须是 2 的幂因为只有这样(n-1) hash才等价于取模而位运算比取模快得多。0.75 这个值是空间与时间的折中源码注释里提到过在泊松分布假设下负载因子 0.75 时桶内节点数达到 8 的概率约为千万分之六这正是树化阈值定在 8 的依据之一。JDK 8 的扩容做了个漂亮的优化不需要重新计算哈希因为容量翻倍后元素的新位置要么在原索引j要么在j oldCap只需看hash oldCap是否为 0据此把原链表拆成 lo、hi 两条链直接挂过去避免了 JDK 7 里每个节点重算索引的开销。第三层是树化。链表长度达到 8 时treeifyBin会被调用但它内部会先检查 table 长度是否达到 64没达到就只做一次 resize 而不树化。这个前置条件是最高频的失分点我第一轮就是栽在这。反过来树节点数量减少到 6 时会退化回链表留出 7 这个缓冲带是为了避免在 7、8 之间反复震荡。另外 JDK 8 把插入方式从头插改成了尾插顺带修掉了 JDK 7 并发扩容时链表成环导致 CPU 打满的老问题——虽然HashMap本来就不是线程安全的但至少不会死循环了。4. 笔试现场最容易翻车的几处细节4.1 equals 与 hashCode 不配对查不到、删不掉HashMap判断两个 key 相等用的是两步先比哈希值哈希相同再调equals。如果你自定义类只重写了equals没重写hashCode两个逻辑相等的对象哈希值不同会被分到不同的桶里map.get(new Key(...))直接返回 nullmap.remove(...)也删不掉但map.size()还在涨。这个 bug 极隐蔽因为集合本身不报错只是行为诡异。反过来只重写hashCode不重写equals默认的equals是引用比较两个哈希相同的不同对象仍然不相等只是会堆在同一个桶里形成链表性能退化但结果看起来正常更难发现。我习惯的做法是只要这个类会作为 Map 的 key 或放进 Set就用 IDE 生成成对的equals和hashCode或者用Objects.equals和Objects.hash手写。另外参与计算的字段必须是不可变的如果对象放进HashSet之后又改了参与哈希的字段这个元素就永远找不回来了因为它被锁在了旧的桶里。4.2 遍历中删元素三种正确姿势和一种经典错误for-each 里删元素是考试和线上的双料常客// 错误示范必抛 ConcurrentModificationException for (String s : list) { if (s.startsWith(a)) list.remove(s); }正确姿势有三种。一是用迭代器Iterator.remove()会同步更新expectedModCount二是用removeIfJDK 8 引入内部就是迭代器实现写起来最干净list.removeIf(s - s.startsWith(a));三是倒序普通 for 循环从size()-1往 0 遍历删除后不会影响未遍历部分的下标。顺带提醒正序普通 for 循环边遍历边删也是错的会漏元素而且不抛异常属于静默错误比抛异常更危险。值得补充的是CopyOnWriteArrayList在遍历时删除不会抛异常因为它遍历的是创建迭代器那一刻的快照你删掉的是新数组里的元素迭代器根本看不见。这个特性适合读多写极少的场景比如监听器列表但绝不适合频繁写因为每次写都要复制整个数组。4.3 泛型擦除编译期过得去运行期炸得响泛型在编译后会被擦除成原始类型ListString和ListInteger在运行时是同一个Classnew ArrayListString().getClass() new ArrayListInteger().getClass()返回true。由此衍生出一串限制不能new T[]运行时不知道 T 是什么不能对泛型做instanceofo instanceof ListString编译不过静态成员不能用类的类型参数基本类型不能当类型参数Listint非法只能ListInteger。重载上的坑更隐蔽void f(ListString a)和void f(ListInteger b)不能共存因为擦除后签名完全一样编译器直接报名称冲突。而ListString和List作为参数却可以共存因为一个是泛型一个是原始类型擦除后签名不同。4.4 自动装箱缓存与的边界Integer a 127, b 127; System.out.println(a b); // true命中缓存 Integer c 128, d 128; System.out.println(c d); // false超出缓存Integer.valueOf会缓存 -128 到 127 之间的实例这个区间是 JLS 强制要求的上限可以通过启动参数-XX:AutoBoxCacheMax调大但下限固定。所以比较包装类型的行为依赖数值范围这属于典型的看似对、其实错。Long也是 -128 到 127Boolean只有两个常量Character是 0 到 127。结论很简单包装类型一律用equals或Objects.equals比较只拿来判 null。还有一个容易忽略的Integer和int混合运算时会发生拆箱如果此时Integer是null直接NullPointerException。三元表达式里混用包装和基本类型也会触发拆箱这类空指针在线上查起来相当费劲。5. 把考点变成工程习惯容量、不可变与选型表5.1 初始化容量怎么算才不浪费ArrayList很简单预估元素个数 n 就直接new ArrayList(n)避免多次扩容拷贝。HashMap则有个容易算错的地方构造参数传的是容量但真正生效前会被tableSizeFor向上取整到 2 的幂而阈值是容量的 0.75 倍。所以如果你的目标是存 n 个元素且一次都不扩容正确算法是int initialCapacity (int) (n / 0.75f) 1; MapString, String map new HashMap(initialCapacity);举个具体例子。要存 100 条数据100 / 0.75 ≈ 133加 1 得 134tableSizeFor(134)返回 256阈值变成 192够用且不扩容。如果偷懒写new HashMap(100)tableSizeFor(100)返回 128阈值只有 96第 97 个元素进来就触发一次扩容前面预分配的意义全没了。这个小细节在性能敏感的批处理代码里差别不小。5.2 不可变集合与防御性拷贝Collections.unmodifiableList(list)返回的是视图不是副本原列表改动会同步反映到不可变视图上所以它挡得住通过视图修改挡不住通过原引用修改。真正的防御性拷贝得用new ArrayList(list)再包一层或者直接用List.copyOf(list)JDK 10——后者会做一次真正的复制且返回的结果不可变。List.of()、Set.of()、Map.of()这几个工厂方法也是常用选择但有两个硬性限制不接受 null 元素传 null 直接 NPE不允许重复元素Set.of(a,a)抛IllegalArgumentException。Arrays.asList()反而允许 null定位不同别混用。返回集合给外部时我现在的习惯是能返回不可变集合就返回不可变的必须可变的话就返回拷贝。这个习惯是被一次线上问题逼出来的——某个 getter 直接返回了内部List调用方顺手clear()了一下结果整个缓存都空了。5.3 一张能直接抄的选型决策表需求场景首选实现关键理由绝大多数有序集合随机访问多ArrayList连续内存、索引 O(1)、遍历缓存友好拿它当队列或栈用ArrayDeque比LinkedList内存更省比Stack少了同步开销需要去重不关心顺序HashSet底层 HashMap均摊 O(1)需要去重且保留插入顺序LinkedHashSet额外维护双向链表代价是每个元素多两个指针需要按 key 排序遍历TreeMap红黑树O(log n)支持范围查询想做 LRU 缓存LinkedHashMapaccessOrdertrue重写removeEldestEntry即可单线程键值存储HashMap综合性能最好多线程读多写少ConcurrentHashMapJDK 8 用 CAS 桶头加锁粒度细读极多写极少且要遍历安全CopyOnWriteArrayList写时复制遍历不加锁这张表我在实际评审代码时常用大部分选错容器的问题对照一遍就能定位。5.4 两周的备考节奏怎么排最后说说时间安排这块是我踩过坑的地方——第一轮我花了一周死磕源码结果真题一套没做上了考场发现题目考的角度和我想的完全不一样。调整后的节奏是前 5 天过知识面数组 1 天、List 1 天、Map 2 天、Set 和工具类 1 天每天配合手写代码验证比如自己实现一个简易的HashMapput 流程比看十遍源码管用。中间 4 天刷题重点刷行为预测类和源码细节类错题必须回源码定位不能只记答案。后 3 天做整卷掐时间模拟考场状态把答题速度练出来。剩下 2 天机动专门补错题本上反复出错的点。还有个我觉得特别有效的方法把每个知识点讲给别人听一遍。讲不通的地方就是没懂的地方。我当时拉着一个刚入行的同事每天下班前花二十分钟给他讲一块内容讲HashMap树化条件那次讲到一半自己卡住了回头翻源码才发现漏了 table 长度 64 的前置判断——那个知识点后来再没忘过。最后再分享一个小技巧做题时遇到以下说法正确的是这类多选题凡是出现一定必然总是这种绝对化措辞的选项先打个问号。Java 集合的行为大量依赖前置条件绝对化描述十有八九是陷阱。这个判断习惯帮我捡回了不少分。

Java数组与集合认证考点：HashMap树化与ArrayList扩容复盘

相关推荐

直流无刷电机AX BY CZ绕组划分与空间轴线全解析

EULA同意管理：从法务文档到可审计服务端状态机

动态技能图谱技术：职业发展的智能匹配工具

更多资讯

下载Python与Pycharm教程（Windows版）

用命令行在 Windows 11 上启用 IIS Web 服务器

AutoHotkey 与 Node.js 集成的完整指南：5 条通路打通桌面自动化与 Web 控制面板

ERPNext 免费 ERP 本地部署：从零跑通财务到制造

vLLM 部署 Hy3 实战：开启 MTP 投机采样的推理加速完整教程

个人工作中对于LangChain的学习

今日更新

AI辅助技术栈评估：提升研发决策效率60%

从生成Token到直接决策：Jev如何重塑AI Agent工程实践

32G统一内存跑大模型：内存账、TPS实测与端云分流

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？

相关推荐

直流无刷电机AX BY CZ绕组划分与空间轴线全解析

EULA同意管理：从法务文档到可审计服务端状态机

动态技能图谱技术：职业发展的智能匹配工具

更多资讯

下载Python与Pycharm教程 （Windows版）

用命令行在 Windows 11 上启用 IIS Web 服务器

AutoHotkey 与 Node.js 集成的完整指南：5 条通路打通桌面自动化与 Web 控制面板

ERPNext 免费 ERP 本地部署：从零跑通财务到制造

vLLM 部署 Hy3 实战：开启 MTP 投机采样的推理加速完整教程

个人工作中对于LangChain的学习

今日更新

AI辅助技术栈评估：提升研发决策效率60%

从生成Token到直接决策：Jev如何重塑AI Agent工程实践

32G统一内存跑大模型：内存账、TPS实测与端云分流

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？

下载Python与Pycharm教程（Windows版）