weixin_313155671. 网盘项目做到一半，为什么突然要回头补“List”的课
最近在做easy网盘项目时，我被一个看起来再基础不过的词反复“绊倒”，就是List。平常写代码，谁不会new一个ArrayList，谁不知道list.add、list.get？可真当项目里每天都要和文件列表、目录树、分享记录、操作日志打交道时，我发现自己对List的理解停在“会用”这一层，遇到设计问题的时候经常答不上来。
起因是某天前端同事说分享模块的一个接口报错，日志里写着“No static resource course/course/list for request '/course/course/list'”。我第一反应是WebMvc配置把URL拦截了，查了半天发现根本不是StaticResource的问题，而是Controller根本没有映射到这个路径，Spring MVC找不到处理器后转去资源目录碰运气，碰不到就把每个路径段打到了报错里。这种带“list”字样的接口路径报错特别有误导性，它会让你以为错误和“列表数据”有关，实际上人家只是在说“这个URL没有任何处理器”。当天晚上我顺着日志翻了项目里的List使用位置，发现从文件列表接口到Redis缓存，再到导出Excel的模板，到处都有List，但每一层我对它的理解都隔着一层纱。于是我列了个清单，把和List相关的知识从头到尾补了一遍，这篇文章就是这次补课的全记录。
1.1 从文件列表接口的“list”报错说起
先把最像“碰瓷”的报错讲透。Spring Boot项目里，请求“/course/course/list”返回“No static resource”并不是因为缺少静态资源，而是DispatcherServlet根本没有找到对应的HandlerMapping。RequestMappingHandlerAdapter失败了之后，请求会落到ResourceHttpRequestHandler去查静态目录，查不到就抛出这个提示。很多团队会把接口路径设计成“模块/动作/list”这种形式，一旦controller类少了@RestController、方法少了@RequestMapping，前端请求就会看到类似“No static resource”的描述。
排查的时候不要被“static resource”带偏，直接看两个地方：一是项目里有没有重复的URL前缀导致路径拼接错误，二是Controller类路径加方法路径是否完整匹配请求。我在easy网盘里遇到的是类上有“/share”，方法上少写了“/list”，前端请求“/share/list”，实际映射“/share”，于是请求就歪打误撞进了静态资源处理器。
1.2 List在easy网盘里到底会出现在哪些环节
我盘了一下整个网盘系统的数据流，发现List不是“某个技术点”，而是一个横跨各层的抽象。前端页面展示文件、分享、回收站，本质是列表页；后端从数据库查出一批文件记录，本质是List
更细一层，目录树虽然看起来是树，但很多实现方式就是先得到一个扁平的List，再在内存里转成树；权限列表是List；附件列表是List；多轮对话的上下文消息也是List。所以“List补充学习”听起来像一个语法课，实际上等于把网盘项目从接口层、服务层、缓存层、存储层、前端展示层都复习了一遍。
1.3 我给这次补课划出的四层路线
为了不让学习变成零散搜索，我把散落的问题归成四条线：第一条是编程语言层面的List，重点搞清楚Java集合框架下List接口的定位、ArrayList执行细节、常见的错误删除姿势；第二条是数据流中间态层面的List，包括Redis List命令、对象网关的list命令输出、启动配置里的白名单校验；第三条是系统工具层面的List输出，比如adb devices、diskpart list disk、apt list，这些“list”是命令而不是集合；第四条是展示与渲染层面的List，从前端的table/list/form控件差异，到POI-TL模板循环List。
这样归纳之后，很多问题突然就通了。后面正式开始。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先把Java集合框架里的List彻底吃透
2.1 List接口在集合家族里到底占什么位置
Java集合里最常被提到的一组名词是List、Set、Map。每次有人问我它们的区别，我喜欢用一个网盘的角色来打比方：List像文件列表，有序而且允许重复，同一个文件可以出现在多个分享记录里；Set像标签集合，每个标签唯一，重复添加会被忽略；Map像文件的扩展名映射表，给你一个key直接返回value，不需要遍历。
从接口设计上看，List继承自Collection，最大的特点是可以通过索引访问元素。ArrayList底层是Object[]数组，查询快、尾部插入快，但是中间插入或删除需要移动元素；LinkedList底层是双向链表，头尾插入删除快，按索引查找却很慢。实际项目里90%以上场景用ArrayList就够了，LinkedList的“链表优势”在JVM连续内存和CPU缓存面前并不明显，尤其数据量没有到百万级以上时，差距可以忽略。
还有一个容易被忽略的实现是CopyOnWriteArrayList。网盘里如果有“正在上传的任务列表”这种组件，会有一个后台线程不断往里加任务、前端线程读取，读写并发高。普通的ArrayList在遍历时被修改会抛ConcurrentModificationException，CopyOnWriteArrayList用“写时复制”解决这个问题。代价是每次写都会复制整个数组，所以它只适合读多写少的场景，任务列表这种低频写入的正好合适。
2.2 new ArrayList<>()不等于立刻分配10个容量
网上很多帖子说ArrayList的默认初始容量是10，这话在JDK 8里严格来说不准确。看源码会发现new ArrayList()的时候elementData指向的是DEFAULTCAPACITY_EMPTY_ELEMENTDATA这个空数组，真正分配容量发生在第一次add时，grow方法里通过DEFAULT_CAPACITY算出10。也就是说，你创建一个空的ArrayList并没有立刻占用10个对象引用的堆空间，而是在第一次添加元素时才扩容到10。
扩容算法是int newCapacity = oldCapacity + (oldCapacity >> 1)，也就是每次增长1.5倍。比如容量10的列表，第11个元素add时会扩容到15，再把原数组复制过去。频繁扩容的代价是复制数组，如果一开始就知道要放几千个文件，最好用new ArrayList<>(expectedSize)指定初始容量。这里有个小坑，指定容量后如果数据量没到阈值，不会触发扩容，但你得预估准确，否则还是白扩一次。另外ArrayList最大容量是Integer.MAX_VALUE - 8，超过会抛OutOfMemoryError，做网盘这种海量文件列表返回时，一定要在接口层做分页，不能让一个List承载几十万条数据。
2.3 两行“List泛型代码”的工程含义
热搜词里有“list
先看List
再看List<Map<String, Object>> tree = new ArrayList<>()。这段代码一看就是“图省事”的写法，想用Map当节点，每个节点里放id、parentId、children，最后整棵文件树就是一个List<Map<String, Object>>。不是说不能用，但工程上非常难受，Map的key没有编译期检查，写错一个字符串根本不报错，等前端拿到数据才发现children没拼上。我后来封装了FileTreeNode类，用List
2.4 删除、过滤、排序：三个最容易写出隐性Bug的地方
List的删除操作是重灾区。最常见的就是for循环里调remove，比如要删除列表中所有等于某个值的元素，很多人会这么写：
java复制for (int i = 0; i < list.size(); i++) {
if (条件) {
list.remove(i);
}
}
这个写法有两个问题：删除元素后索引会重新排列，i继续自增可能导致跳过下一个元素；如果用增强for循环，删除过程中modCount变化，ConcurrentModificationException直接找上门。正确的是使用迭代器删除，或者一行removeIf：
java复制list.removeIf(item -> item.getStatus() == 1);
还有一个隐藏很深的问题是Arrays.asList。我遇到过同事把数据库返回的数组转成List后尝试remove，结果抛UnsupportedOperationException。原因是Arrays.asList返回的是Arrays内部的一个固定长度List，底层仍然是原始数组，不支持结构性修改。这个List和ArrayList只是名字像，实际上是两个类。
排序方面，注意sort是稳定排序，可以用Comparator.comparing(Foo::getCreateTime).reversed()这种链式写法。如果你要排序的字段可能为null，建议使用Comparator.nullsLast或nullsFirst，否则一行NullPointerException会让整个列表接口挂掉。这里所有的经验都说明一件事：List不是“存东西的数组”那么轻量，它自带一套并发、扩容、排序、视图的规则，用错一次就要查很久。
3. 顺着网盘数据流往下摸：Redis List、对象网关与配置白名单
3.1 Redis里的List到底适合存什么
网盘项目里除了数据库，Redis是最常用到的中间件。Redis的五大数据结构中，List经常被我用来做三件事：最近的浏览记录、文件预览任务队列、操作日志的暂存。List在Redis里的语义是“有序字符串列表”，你把一条记录LPUSH到左侧，用LRANGE 0 99取前100条，再用LTRIM 0 99裁剪长度，就得到了一个“只保留最近100条记录”的列表。
有人会把Redis List和数据库表混为一谈，其实它们差异很大。数据库表支持按任意字段查询，Redis List只支持按索引范围和队列头尾操作。如果你想在网盘后台页面展示“最近用户操作”的搜索分页，还是老老实实放数据库，Redis List只适合做访问性极强、数据量可控的有序集合。比如网盘首页的“最近文件”侧边栏，直接从Redis里LRANGE取，比查数据库快一个数量级。
3.2 LRANGE分页和消息队列的取舍
我见过有人拿Redis List做业务分页，用LRANGE start stop去实现“第几页”，数据量小的时候没问题，到了几千条时依然能扛，可一旦并发高了，每次分页都要跨网络传输整个区间，性能开始下滑。List真正的强项是“消息队列”，通过LPUSH + BRPOP组合，左侧生产者push，右侧消费者阻塞式pop，天然实现了一个FIFO队列。BRPOP会阻塞直到有数据，不会像轮询一样消耗CPU。
easy网盘里有一个文件转码任务，用户上传视频后服务端把任务push到转码队列。Redis list在这里非常适合，团队后来还在消费者端加了重试上限，防止任务卡死。写命令时要区分“操作Redis list的命令”和“Redis字符串的的命令”，很多人到Redis里敲一个list命令发现不存在，因为Redis没有单独的“list命令名”，List类型对应的是一组命令，比如LPUSH、RPUSH、LPOP、RPOP、LRANGE、LLEN、LTRIM、BRPOP。这一点和MySQL里SHOW TABLES这种动词型命令思路不一样。
3.3 对象网关侧的list bucket.instance到底在列什么
easy网盘的对象存储部分使用了RadosGW，这是Ceph的S3兼容网关。遇到桶和对象不一致的问题时，我常需要查看元数据。命令是：
bash复制radosgw-admin metadata list bucket.instance
注意这里的list不是集合操作，而是radosgw-admin的一个子命令，列出的是所有bucket instance的元数据标识。返回结果一般会是一堆bucket信息，里面能看到bucket名称、owner用户、创建时间等字段。如果想看某一个桶的完整配置，可以先用这个命令找到instance id，再配合get命令拉详情。
排查“list of devices attached”这类问题时要有一个习惯：先明确命令输出的每一列是什么意思，再看空值是不是合理。bucket.instance元数据列表如果为空，可能不是没有桶，而是用户没有权限或者网关实例连接有问题。我曾经在集群里因为rgw的socket连接断了，metadata list直接空转，看起来像“没有任何桶”，实际是服务已经假死。
3.4 “value not in list”这类报错暴露的配置检查逻辑
热搜词里有一条很特殊的报错：“value not in list: vae_name: 'minimaxh3\minimax_h3_audio_vae_fp32.safetensors'”。这看起来像AI模型启动时校验VAE文件名不在允许列表中。这种设计其实很多后端项目都有：启动时把可选值整理成一个List，然后校验传入配置是否在白名单内，不在就快速失败，避免运行时才暴露。
网盘系统同样也需要这种白名单，比如允许的图片缩略格式、允许的转码分辨率、允许的文件类型。我一开始把这些值硬编码在if判断里，后来改成配置驱动：定义List
4. 设备、磁盘和软件包：一屏“list”输出背后的系统排查
4.1 adb devices卡在list of devices attached怎么处理
easy网盘配套的Android客户端在调试时经常要用adb devices确认设备被识别。终端执行后，如果只输出“List of devices attached”这一行，下面没有任何序列号，说明设备没有连接成功。常见原因按概率排序是：服务没起来、驱动问题、权限未授权、端口被占、数据线不支持传输。
服务异常的处理最直接：
bash复制adb kill-server
adb start-server
adb devices
如果无效，检查手机USB调试有没有开、手机上是否弹出“允许USB调试”的授权窗口，有些机器需要撤销授权后重新插拔。然后确认数据线是不是只支持充电，很多廉价线没有数据通道。Windows系统还会遇到驱动问题，设备管理器里能看到带感叹号的设备节点，这时候更新驱动即可。还有一个隐蔽问题，5037端口被其他程序占用，启动adb服务会失败，用netstat -ano | findstr 5037排查。
开发工具里“list of devices attached”其实是一个很有用的状态提示，它表示“本条命令会输出设备列表”，下面为空只是结果为空。很多人把它当成错误提示，定位方向就错了。
4.2 diskpart的list disk无法识别磁盘的排查链路
另一个常见的list命令是diskpart里的list disk。在Windows服务器上做网盘存储节点扩容，新插了块盘，打开diskpart执行list disk却看不到新磁盘。这时我不会继续在diskpart里折腾，而是按链路排查：先看物理链路，SATA/SAS线有没有插牢、硬盘有没有通电转动；然后看系统层，进入设备管理器看磁盘驱动器是否多了一个未初始化的设备，再进入磁盘管理确认是否显示“未知/未初始化”。
diskpart的list disk只能列出系统已经识别并且有正确驱动的物理磁盘。如果系统不识别，这里当然没有。还要注意管理员权限，diskpart必须以管理员身份运行，否则有的系统只读。最后一种情况是控制器驱动版本太旧，大容量硬盘无法正确识别，需要更新主板/阵列卡驱动。这个排查思路和我们在服务端看“List为空”完全一致：先确认数据源有没有，再确认读取链路上哪一环断了，而不是对着空的列表发呆。
4.3 apt list --upgradable与Linux软件包更新核对
在Linux服务器上部署easy网盘时，登陆时终端经常会提示“有 N 个软件包可以升级。请执行 ‘apt list --upgradable’ 来查看它们”。这句提示不是系统故障，而是列出可以更新的包。每次做变更前我会先执行查看，确保不会意外升级到不兼容版本：
bash复制sudo apt list --upgradable
这个命令输出所有能升级的软件包及当前版本、目标版本。我一般会配合grep过滤关键组件，比如nginx、java、mysql相关的包。真正执行升级前还要看changelog，不是一键apt upgrade。网盘服务如果跑在老旧环境里，冒失升级系统库可能导致客户端连不上，这种“list”输出是提醒你决策，不是让你直接动手。
4.4 Windows服务依赖错乱也能扯上list
热搜词里有一条“与 network list service 服务相依的 network location awareness 服务因下列错误而停止”，第一次看以为是网络配置问题，追了一圈发现是Windows服务之间的依赖顺序出了问题。Network List Service依赖Network Location Awareness服务，如果NLA没起来，NLS也启动不了。排查时肯定要去服务管理器里看依赖关系列表，右键服务打开“属性-依赖关系”就能看到一串服务名。
这个场景对应的经验是：当系统提示某服务因依赖服务出错而停止，不要只盯着报错的服务修复，要往上找依赖链。就像List里的每个元素如果携带了子List，父子关系有一个环就全乱了。Windows服务依赖管理和文件树构建本质上是一个“有向无环图”问题，只是工具把这些关系以列表的形式展示出来。
5. 从代码到界面：List在表格控件、Word模板里的翻译过程
5.1 table、form、list、slip四个英文词背后的UI模型差异
网盘前端会上传组件、文件表格、日志流水，桌面软件里To-Do List也常被翻译成列表。英语表达table、form、list、slip看着都能翻成“表格”，实际差异很大。
table适合二维数据的展示与对比，文件列表用table最合理，表头是文件名/大小/修改时间/分享状态，行是具体文件，用户能快速横向比较；form是“表单”，强调一个对象属性的录入与编辑，例如上传文件时的标题、标签、权限等，字段聚集在一张卡片里，而不是一排一行；list是线性数据，适合浏览、点击进入详情，例如“最近分享记录”侧边栏；slip的本意是纸条、小票，更多用于时间流、回执流水，强调逐条记录按时间顺序展开，例如操作审计日志。
拿easy网盘的界面选型举例：文件管理主界面用table，因为用户要比较多个文件的大小和修改时间；上传对话框用form，因为要做一系列输入；左边“最近浏览”用list，每条只有文件图标和名称，点击就跳转；而“当前账号的登录流水”适合slip式时间线。设计与开发之间最容易出问题的是，产品经理说“给我一个列表”，开发就整了一个table，但需求可能只是list就够。先在数据维度上达成一致，再谈组件实现，可以避免很多返工。
5.2 POI-TL模板怎么渲染List，网盘导出Word的实战
easy网盘里有一个导出操作：把某段时间内所有文件分享记录生成一个Word报告。用POI-TL渲染列表时，需要借助{{表达式}}实现循环。例如模板里写好：
code复制{{?logs}}
时间：{{time}}
操作人：{{operator}}
{{/logs}}
POI-TL会识别?和/包围的区域，并将该区域按List长度重复渲染。它的底层机制是在模板中找到标签所在行，循环复制那一行，然后用数据模型里的List逐行填充。这里面最容易踩的坑是模板里标签所在的行不能有合并单元格或嵌套段落，否则复制出来的行结构会乱。另一个坑是如果List元素属性是另一个对象，比如每条日志包含一个user对象，模板里写成{{user.name}}，但数据源是Map而不是对象，两个层级解析会失败。我在项目里统一把数据模型转成POJO，不用Map，问题少了一大半。
POI-TL的另一个注意点是list标签与表格行标签不兼容。如果模板里是一个普通表格，想通过一行循环生成多行，POI-TL也能处理。更麻烦的是导出内容中有图片，比如列表里每个文件有一张缩略图，模板标签需要指定width和height。开发前最好先做一个小样实验，确认模板循环能跑通再开始写业务代码，否则等业务代码写完了才发现模板引擎能力不足，返工成本很高。
5.3 前端拿到List之后：转树、转Map、排序的顺序话术
网盘文件树是一个典型场景：后端返回一个扁平的List
标准解法是用Map先建立索引，再遍历两次：
javascript复制const map = new Map();
const tree = [];
list.forEach(item => map.set(item.id, { ...item, children: [] }));
list.forEach(item => {
const parent = map.get(item.parentId);
if (parent) {
parent.children.push(map.get(item.id));
} else {
tree.push(map.get(item.id));
}
});
这里Map承担的是“索引列表”的职责，把每次查找从O(n)降到O(1)。顺序上有个容易忽略的点：一定要先完成全部children数组初始化，再执行第二次遍历。有人想在一次遍历里同时处理父子关系，结果会出现父节点还没创建就找不到Map元素。真实项目还要考虑循环引用，防止两个节点互为父子导致死循环，我在组装后加了一层环路校验，把指向链路上的节点数量作为阈值，超过则判定存在环。
前端对List的处理顺序同样有讲究：先去重，再排序，最后转树。如果先转树再去重，重复节点会变成多条分支；如果先排序再转树，同层节点就已经按规则排好，可以省略树内部的排序操作。
6. 不止Java：Unity、APDL、EndNote和RPG Maker里的“List”
6.1 C#里List转Dictionary时为什么会炸
Unity项目里常出现把List转成Dictionary的需求，比如运行时根据物品ID快速查找对应的道具配置。C#代码通常是：
csharp复制var dict = list.ToDictionary(item => item.Id);
这段代码在列表里有两个相同Id时会抛异常：An item with the same key has already been added.KeyValuePair。原因很简单，Dictionary要求key唯一，而List允许重复元素。处理方式是先用GroupBy过滤或改成ToLookup：
csharp复制var dict = list.GroupBy(item => item.Id)
.ToDictionary(g => g.Key, g => g.First());
这跟Java的Collectors.toMap遇到重复key默认抛IllegalStateException是同一个道理。List的“允许重复”特性本身不是bug，转换成Map这种唯一键集合时才会暴露。以后看到“List转Dictionary报错”不要觉得平台奇怪，任何集合转换先问一句：“这个列表里的元素在目标结构中是否天然有唯一键”。
6.2 APDL提示list results status is available only in POST1说明什么
用ANSYS APDL做结构分析时，终端里敲命令想把结果列出来，系统提示“list results status is available only in post1”。这句话的意思是，你要列的结果状态只有在POST1后处理器中才存在，当前处于PREP7前处理或者SOLUTION求解模块，根本没有结果数据可供展示。
这个场景放到网盘项目里很好理解：文件列表接口可能只有在某个服务状态激活时才被允许查询；任务日志可能只有任务结束之后才能拿到完整状态。APDL的报错提醒我，很多“list”不是单纯地读数据，而是受“当前运行环境/阶段”约束。调试时先确认你位于哪个处理器、哪个状态，比盯着语法看半天更有价值。比如网盘系统里“试看文件任务状态列表”只能在文件转码状态机推进到某一步后才能查到，代码里体现为状态枚举校验，不在合法状态就返回空列表或业务异常，而不是一股脑把0和1全部抛给前端。
6.3 EndNote、RPG Maker与To-Do桌面软件给List产品化的启示
EndNote里的期刊缩写list，在写论文时能按期刊标准格式自动替换缩写；RPG Maker MV的Master Plugin List，管理游戏插件的加载顺序和参数；各种To-Do List桌面软件的核心理念则是把待办事项排成有序、可勾选、可排序的列表。这三类产品都把“List”当成核心信息架构，因为人类大脑处理列表比处理网状结构更省力。
但产品化的List不是简单存一组数据，而是给List附加“规则”：EndNote的list每个条目都有全称、缩写、类型；RPG Maker插件List有依赖关系和启用状态；To-Do应用每件事有优先级、截止日期、完成状态。回到easy网盘项目，文件列表如果只有文件路径，那是贫瘠的List，加上修改时间、版本号、上传人、校验值、共享状态，才是一个具备操作价值的数据集合。这个认识帮助我不再把List看成一个数组，而是看成一类“可迭代的业务实体集合”。
6.4 一个容易被忽略的URL：phpm=goods&a=list
在网盘项目里排查PHP旧系统时，见过“phpm=goods&a=list”这样的query参数。这里的list没有技术深意，只是模块的动作参数，等于告诉后端“请返回商品列表”。很多技术名词在URL里只是可读性标识，不能一看到list就把它跟Java List联系起来，更不能因此在日志里大海捞针。它提醒了我：先理解URL的语义，再去代码里找对应的Controller方法，比在全局搜“list”要快得多。
7. 补课之后的代码返工：我在easy网盘里做了哪些减法与加固
7.1 文件列表接口不再无脑返回List
补课之前，easy网盘的文件列表接口返回的是List
有人可能会问，List本身没错，错在数据量不分页。这话对，但也不全对。接口返回的裸List没有元数据，前端不知道总共有多少数据、还能不能继续加载。分页结果里带上total/是否还有下一页，对前端体验影响非常大。另外还要限制单次最大返回条数，即使前端传pageSize为10000，后端也强行截断到200，从服务端保护自己。
7.2 文件树的组装减少无效查询与无效节点
原来的代码构建目录树用递归，每个节点的子节点各查一次数据库，文件夹一多就出现N+1查询。补课之后改成“一次查全量+内存组装”。步骤是：先查出当前用户可见的所有文件夹List，然后基于Map构建父子关系。核心技巧是Map<Long, FileTreeNode>，第二次遍历时判断parentId是否存在，不存在就放到根节点。
这个方案里有两个坑：一是全量查询可能把用户无权限的文件夹带出来，需要在查询阶段或组装后过滤；二是如果父文件夹已经被删除而子文件还残留在List里，这些孤儿节点要单独收集，记录到异常日志中，不能直接丢弃。我在做了这些加固之后，文件树接口的响应时间从几百毫秒降到几十毫秒，更关键的是日志里再也看不到一堆重复的SQL。
7.3 给Redis队列和导出任务加上边界与兜底
工程里不能只有正常路径，List使用场景也一样。Redis的操作日志列表，我会用LTRIM设置上限，比如只保留最近5000条，防止内存被无限增长的操作记录拖垮。消息队列的消费端加上超时、重试和死信标记，文件转码任务在Redis列表里弹出后失败，立即重新放回左侧并计数，超过3次挪到专门的失败列表。这份“额外功课”既是对List数据结构操作边界的理解，也是对系统稳定性的负责。
POI-TL导出模板我也做了改动：渲染前先校验模板文件是否存在、占位标签是否齐全，如果List数据为空，会给默认文案“暂无记录”，宁可少导出，不导出半截坏文档。所有List操作在我的代码里都像数据库事务一样考虑边界条件，其实就是把“列表循环”从单纯业务需求升级成完整的数据处理流程。
7.4 把“补充学习”做成项目里的固定存档点
这轮补课给我最大的收获不是记住了ArrayList扩容倍数，而是养成了一个习惯：项目中遇到任何一个反复踩的通用概念，都单独建一个存档笔记，里面记录原始问题、排查过程、结论。这次整理的一篇叫collection-list的笔记，里面包含了源码片段、命令例子、模板写法，已经有几千字。下次团队里再有人问“list of devices attached怎么解决”“POI-TL怎么渲染List”，我直接把笔记链接丢过去，不用再从零解释。
存档分类就按我前面说的四层：数据结构的List怎么用、系统命令的list输出怎么看、业务层的List怎么设计、前端展示层的列表怎么配合。这种方法在项目里可以复制到任何知识点上，不必把“补充学习”限定在List本身。以后项目里出现新的疑问，我都会先按这个思路存一个“xxx补充学习”笔记，再定期回头更新代码。
这轮补课以List为圆心，实际上把easy网盘从接口层到存储层到页面层都过了一遍。下次再看到“list”这个词，我不会再下意识只当成一个集合，而是会先问一句：“这里说到的list，究竟是内存里的对象集合、Redis里的队列、命令输出里的记录，还是界面上的表单与表格？”问对了问题，答案往往已经清楚了一大半。