寒假训练周报2这份周报的主要话题不只是“这周练了什么”更想复盘从第一周到第二周之间训练节奏发生的真实变化。如果你也是趁着假期给自己安排技术训练的在校学生、刚工作的开发者一个人默默刷题或者做点小项目那这篇内容里不少细节应该能对得上号。第一周我的状态是典型的“开局用力过猛”买了计划本、加了几个打卡群、把一天切成了七八个时间段结果头三天确实热血后面就开始滑水。到了这周我彻底放弃了那种“精确到分钟”的日程表换成了按块分配精力居然找到了更稳的节奏。所以这篇周报我会从训练总览、实际训练量、算法从“看懂”到“写对”的质变、项目从模仿到自用、踩坑复盘以及下周训练调整这六个维度往下写尽量把每一个决策背后的原因也说出来而不是只摆一个数据。1. 从“排满日程”到“守住节奏”第二周训练总览先交代一下这个寒假训练的整体框架不然单看第二周数字会有点孤立的观感。假期开始前我定下来的四条主线一直没有变算法与数据结构每天保持一定题量按专题推进。项目实战独立做一个真正可给自己使用的小工具。计算机基础补充操作系统、网络、数据库交叉着看。输出与复盘每周一篇周报平时随时记录笔记。第一周的教训是这四件事同时推进但不能平均分配时间也不能按“今天必须全部完成”来要求自己。基于这个经验第二周我把作息调整成早中晚三个大块上午状态最好用来死磕算法下午基本精力平缓适合写项目晚上只做输入类的事比如看书、看技术视频、整理笔记不再安排高强度的编码。这和很多人推荐的“晨间强力工作法”其实是一回事只不过我从第一周的“机械执行”变成了“按精力分配任务”。直接的体现是第二周每天的集中学习时间稳定在四到五个小时左右周末稍多一点但比第一周少了两小时左右整体产出却更高。这说明一个简单的道理训练质量看的是有效投入不是椅子上坐多久。第二周具体推进的情况我列成了表格方便对比训练方向本周目标实际完成主要产出算法与数据结构滑动窗口、哈希表、二叉树遍历三个专题15道新题 9道复习题通过数44道专题错题笔记一份项目实战命令行版打卡工具v0.2多完成一个统计功能可本地运行数据写入SQLite计算机基础看完网络分层前3章完成2章阅读、8条笔记笔记卡片输出复盘每周至少3条学习日志完成5条周报素材累积表里的数字并不惊人也不打算制造焦虑。我自己更看重的是“连续五天保持住节奏”这件事。假期训练最怕断档一旦断两天重新捡起来要付出额外成本这一周我每天都在固定的时间坐到书桌前其实就已经赢了一半。当然第二周也不是一帆风顺中间出现过一天因为家里有事完全空了我当时的处理方式是当天不补任务第二天照常推进后面会专门说为什么我建议大家这样做而不是一上来就加倍追进度。2. 训练量盘点第二周到底练了多久时间都去哪了如果只看标题“寒假训练周报2”可能有人觉得训练统计是最没意思的部分但我恰恰认为这是整个假期计划里最值得公开讨论的事情。没有记录就没有复盘没有复盘训练计划就只是一张废纸。先说总投入时间。我用手表自带的计时器和项目里的记录方式双重统计第二周合计约31.5小时分布如下算法与数据结构10小时项目开发与调试12.5小时计算机基础阅读5小时学习日志与周报2.5小时每周复盘与计划调整1.5小时这31.5小时看着不少但真正高效的其实只有上午那两小时和下午前半段。晚上我经常一边看书一边犯困阅读效率能打个七折。为此我还专门测了一下一天里注意力曲线基本符合最常规的生理规律上午9点到11点是黄金期下午4点到6点有一个小幅回升晚上8点以后进入平稳下滑。既然测量出来是这样就不必硬逼自己在晚上刷难题把晚间安排成输入型的阅读是更聪明的选择。第二周我还开始记录“专注长度”。每段训练用番茄钟切分25分钟为一个单位中间休息5分钟。不太理想的地方是算法题经常一个番茄不够用比如一道中等难度的题目从理解到通过可能要三个番茄中途打断反而影响思路。后来我调整成“写完一个完整解题过程再休息”不一定严格对齐25分钟。这件事给我的启发是工具是辅助不是目的如果番茄钟影响心流了就大胆调整它。除了时长之外我也在记录“产出件数”。时长比起产出件数更容易骗人比如有时候断断续续学了三个小时真正有产出的只有四十分钟。这一周的产出件数是15道新题、9道复习题、5条学习日志、项目代码迭代三个版本、8条阅读笔记。这些产出件数才是判断计划是否有效的核心指标。训练量盘点里还有一件事需要提一下就是睡眠。我发现第二周晚上睡得比第一周晚平均延迟了大概40分钟原因是总想趁着白天计划完成得不错想在睡前“加个钟”多看点东西。这个信号其实不健康假期的训练不是冲刺而是一场需要跑完整个寒假的马拉松。睡眠一旦压缩白天的注意力和记忆都会受影响尤其影响算法这种需要高强度思考的事。所以我给自己定了条硬规矩最迟晚上十点半合上电脑宁可任务留到第二天早上也不能牺牲睡眠。3. 算法训练从“看懂官方题解”到“第二天不看题解重写”第二周的算法训练是我最有体感的一段。第一周我刷了不少题但有一个真实状态就是看题解能看懂合上题解自己写就卡住。第二周的转变不是因为我突然变聪明了而是我试着改变刷题方式。先说本周的题目范围。我在第一周把链表、栈、队列的基础题扫了一遍第二周进入三个新专题滑动窗口、哈希表、二叉树的前中后序遍历。这三个专题属于面试和日常开发都比较常见的内容难度梯度也比较合理。其中印象最深的一道题是典型的滑动窗口求最长无重复字符子串。这个题很多人应该见过我第一周用暴力法写过一次提交直接超时。第二周我重新按照专题去理解它的运行逻辑写完这题之后我对滑动窗口的理解才真正成型。这个题的核心原理并不难右指针一步步向右扩展窗口新字符进入窗口如果窗口内出现了重复字符就把左指针向右移动直到重复消失。整个过程每个字符最多被左右指针各访问一次时间复杂度能从暴力的O(n²)降到O(n)。我用Python写了核心实现基本可以当作滑动窗口题目的通用模板来用def max_unique_length(s: str) - int: left 0 char_index {} max_len 0 for right, ch in enumerate(s): if ch in char_index and char_index[ch] left: left char_index[ch] 1 char_index[ch] right max_len max(max_len, right - left 1) return max_len别看这段代码很短背后的关键细节不少。第一次我写的时候漏了and char_index[ch] left这个条件导致什么结果窗口明明已经把左边的某些字符移除了但哈希表里还存着它们的旧下标这时遇到旧的下标就会错误地把left拽回去输出结果偏大。这就是一个非常典型的“哈希表保存历史状态”引发的坑也是很多人在滑动窗口上面反复出错的原因。写完这道题之后我没有立刻刷下一道而是做了这样一个动作把官方题解里的滑动窗口框架用自己的语言重写一份放在笔记里。第二天早上我重新拿出一张纸什么参考都不看直接默写这个框架并尝试解一道同专题的新题。这个“延迟重写”的动作比当天反复刷新题还有用。为什么会这样因为当日记忆的痕迹还在重写时容易变成机械复述过了一夜大脑会在睡眠里做记忆整理第二天再写剩下的往往才是真正内化的东西。这是我这个寒假学到的关于算法学习的一个核心经验看懂不等于会写会写不等于能独立写。真正有效的检验标准是隔一天之后能不能从零写出解法。本周算法训练中我还做了一个值得记录的小实验把每道做错的题归类成错误类型而不是只记“这题我不会”。我大概统计了本周所有提交的报错情况做一个异常原因的对比错误类型出现次数典型表现对策边界条件漏判6次空数组、单元素、整型溢出写代码前先列边界样例逻辑结构写错5次循环里更新时机不对在白纸上模拟一次流程数据结构用错4次该用哈希却用了双循环先想复杂度再选结构手误/复制错误3次变量名拼错、数组下标写错写完先全篇自查一遍这份统计让我意识到绝大多数提交失败并非因为“思路完全不会”而是因为没有在一开始就把边界条件和数据结构想清楚。也就是说如果每次做题都先花三分钟在纸上写清楚输入边界、状态变化顺序平时的提交通过率会高很多。4. 项目实战把一个教程Demo改造成自己每天都在用的工具第二周项目上最重要的决策是决定不再照着视频一行行敲Demo而是把头两天做出来的命令行打卡工具拆了重来加入我真正需要的功能。这个转变值得展开讲。第一周我跟了一个教程做的是一个很常规的todolist命令行工具虽然能跑但我其实不太会用。原因很简单它记录的任务和我的真实学习目标对不上也无法生成每周统计。到了第二周我把它升级成了“寒假训练打卡工具”用Python标准库里的argparse做命令行参数解析用sqlite3做持久化存储全程不依赖任何第三方库。为什么不用Django或者Flask做网页版因为当前阶段的训练目标是理解核心逻辑不是做一个漂亮的界面。用纯标准库逼迫自己去思考数据怎么存、参数怎么解析、怎么处理冲突这些能力在以后用任何框架时都是通用的。而且命令行工具启动快不占资源适合假期里每天高频使用。我设计的核心功能有三个添加打卡记录、查看当天情况、按周输出训练统计。实现的思路不复杂但踩坑过程很有价值。我挑其中最关键的几个点说。第一点是SQLite的连接生命周期问题。第一个版本里我几乎在每个函数内部都新建数据库连接导致频繁出现database is locked。后来才想明白对于这种单进程小工具应该全局只维护一个连接操作完用with语句提交事务而不是反复开关连接。修改后的核心代码大致是这样的结构import sqlite3 import argparse from datetime import date DB_PATH train.db def get_connection(): return sqlite3.connect(DB_PATH) def add_record(project: str, hours: float, note: str ): with get_connection() as conn: conn.execute( INSERT INTO records (project, hours, note, record_date) VALUES (?, ?, ?, ?), (project, hours, note, date.today().isoformat()), ) def stats(): with get_connection() as conn: rows conn.execute( SELECT project, SUM(hours) FROM records GROUP BY project ).fetchall() return rows这里有一个值得单独说明的细节使用参数化查询?占位符而不是把用户输入直接拼接进SQL字符串。刚开始我图省事直接用f-string拼接输入虽然自己用的时候没什么问题但这属于非常恶劣的习惯。一旦输入里出现引号或特殊符号轻则程序崩溃重则产生注入风险。即使这是一个只给自己用的工具也应该从一开始就写正确写法。第二点是argparse的一个隐性坑。我在设置命令行参数时想用--week-day表示周几结果程序里访问变量名发现怎么都取不到这个值。查了半天才意识到argparse会把参数名里的连字符-自动转换成下划线_所以--week-day对应的属性是args.week_day不是args.week_day。这个坑特别小但极容易让人困惑尤其是在参数很多的时候。项目这一周的产出不只是功能代码。我还额外画了一张简单的状态迁移图记录数据从用户输入到写入SQLite、再从SQLite输出统计的完整路径。没有用什么高端画图工具就是白纸加笔。这个动作看似多余但它让我在调试时有了全局视角不再是东试一下西试一下。第三点是“工具会改变行为”。我把打卡工具做到能统计每周小时数后发现自己的行为立刻发生了变化因为系统能展示每天各方向投入的比例。比如某天算法只练了半小时晚上一看统计心里就有数了第二天会不自觉地调整。这就是“可观测性”带来的自我修正。如果你也在做个人项目我非常建议优先把数据的统计和展示做出来哪怕是最简单的文本表格它的驱动力比各种自律软件都大。项目目前还存在一些很明显的不足没有数据删除功能打卡输错了只能手动进数据库改没有周报自动生成每周还是靠复制几段SQL查询结果。这些我放在了下周的迭代计划里属于“明确知道但暂不处理”的清单。5. 踩坑复盘第二周被几个低级错误连续教做人作为“寒假训练周报2”如果通篇只写练习计划和项目进展少了一块非常重要拼图训练过程中实际踩过的坑。这周我特意把每次调试记录在单独的文档里现在复盘下来发现一个共性这些坑几乎都不是因为原理不懂而是出在操作习惯和细节意识上。第一个坑是SQLite的database is locked。症状很直接程序连续执行几次写入后某次插入就抛出这个异常。第一反应我以为是并发问题后来查了官方文档确认问题出在我每个函数都创建新连接事务没提交完毕连接就断开了。解决办法就是上一节说的全局保持单连接写入后统一commit。这个坑的教训可以推广到很多场景遇到数据库锁问题优先检查连接生命周期而不是急着上缓存或线程。第二个坑是argparse的下划线转换这个上面已经提到。这里我想补充的是这种小坑记录在笔记里的价值在于下次再遇到“命令行传参进去但程序拿不到值”的问题时可以马上想到这一层而不是浪费半小时查文档。第三个坑比较隐蔽发生在阅读二叉树遍历的时候。我在本地用Python写了前序遍历的递归版本逻辑完全正确却被一个全局变量污染问题缠住了。我在类里初始化了一个result []作为全局结果列表然后又在一个方法内部用了同名的局部变量导致方法运行后结果丢失。查错的过程花了快四十分钟最后打印各层变量id才发现两个result根本不是同一个对象。这个坑其实属于Python作用域的基础知识但在实战中踩着的时候解决问题的流程比知识本身更能留下深刻印象。第四个坑不发生在代码里而是发生在学习方式上。某天算法训练时我连续做了四道关于哈希表的题到第三道第四道明显感觉到自己在机械套模板题目读得不仔细甚至出现读漏条件的情况。当时的反应是还想硬撑觉得“今天目标还没完成”。现在想想这个想法很危险训练是为了提升能力不是为了凑数量。最后我停下来休息了十五分钟再做状态才恢复。如果你的训练中也出现“题目读不进去、样例跑不出来”的状况别硬扛大脑需要的可能只是短暂的休息。把这几个坑整理成表格便于后来阅读现象根因排查过程解决办法SQLite报database is locked每个函数各建连接事务混乱查官方文档、看日志全局单一连接统一提交argparse取不到参数连字符被转成下划线打印args变量结构使用下划线属性名result列表丢失局部变量覆盖全局变量打印变量id定位统一命名避免遮蔽连续刷题状态下降注意力疲劳意识到读题变慢强制休息不硬扛把这周的情况放到更长的时间线里看这些坑都不是大事但重复的次数多了就会变成真实的效率损耗。这也是我坚持做踩坑复盘的原因花十分钟记录一个坑未来可能省下几个小时。6. 下周训练调整计划不是死规矩是基于反馈迭代出来的最后一个章节写下一周的具体调整方案。很多人做训练计划时会犯一个错误计划定下来就跟法律条文一样不能改每天必须严格按照表格执行。我第一周就是这种心态结果撑了三天就开始产生抵触心理。第二周我转变思路把训练计划当成一个“需要持续反馈迭代的系统”情况立刻好转。先说算法方向。滑动窗口这个专题做完之后我明显发现自己的弱点集中在“如何把窗口的状态维护清楚”尤其是窗口收缩的时机。下周我会花两到三天继续做3到5道滑动窗口的巩固题然后转向动态规划的入门专题。动态规划是我一直有点害怕的领域但按照第二周的经验我应该先把最经典的背包问题吃透再考虑进阶。接下来是项目迭代。打卡工具v0.2已经可以用但还缺最关键的周报导出功能。我计划在周一完成数据统计模块的重构让它能直接输出Markdown格式的周度训练总览。这个需求其实是从我写周报的痛点来的每次写周报时都要手动去SQLite里查数据非常低效。如果我能让工具直接生成统计段落以后每周的周报写作速度会快很多。计算机基础这部分下周会从网络分层转到HTTP协议。目标是搞清楚一个完整请求从浏览器发出到服务器返回中间经历了哪些环节每个环节里哪些信息被加工和传递。我的方法还是一样阅读为主但每看完一章就尝试用大白话复述把复述内容写到笔记里。这种输出式的学习比单纯划线要有用得多。除了具体内容还要记录两个训练制度的调整第一把每天上限定为五个小时每周安排一天完整的休息日。寒假训练最怕的不是练得少是练到中途彻底失去动力。我宁愿每天五小时稳定推进也不想某天状态好在书桌前坐十个小时第二天头脑发胀什么都做不动。第二允许“不完美的执行”。比如计划里安排了下午三小时写项目实际只写了一小时就卡住了那就停下来复盘卡住的点是什么而不是硬撑着写下去。有效的复盘比无效的耗时更值钱。按照这个思路我列出了下周的粗略训练表日期算法/上午项目/下午基础/晚间周一滑动窗口巩固2题重构统计模块HTTP协议第1章周二动态规划入门周报导出功能HTTP协议第2章周三背包问题基础2题联调测试整理笔记周四背包问题变体界面提示优化HTTP协议小结周五动态规划复盘文档与使用说明休息前复习周六综合复习自由项目时间周报素材整理周日休息休息周报撰写表格往下看可能有人注意到我周六还在安排训练周日才正式休息。结合我自己的实际作息把周报撰写放在周日晚上是顺手的也正好可以利用周六的状态把训练数据整理好。这个节奏可以在下一周运行之后根据实际情况再微调。最后说一个小小的体会。第二周训练结束后回头看最先浮现在脑海的并不是具体某个算法或某行代码而是“每天到点坐在书桌前”这个过程的重复感。这种重复感并不乏味反而带来了稳定感。如果你也正在寒假坚持某种训练无论内容是什么希望这份周报里的记录方式、调整思路和踩坑笔记能给你一点参考。状态有波动不可怕可怕的是为了避免波动而彻底放弃这也是我这周感受最深的一句话。