“学习日志2”——这个标题本身没什么技术含量但如果你真的坚持写过学习日志就会明白“第二篇”三个字的分量。我复盘过自己过去几年的学习记录发现一个特别残酷的规律绝大多数人的学习计划不是死在“开始”那一秒而是死在“第二篇日志”。第一天写第一篇时人还在鸡血状态工具装好了、笔记建好了、路线图规划得比上市公司战略还周密恨不得把键盘敲出火花。可到了第二篇真实的学习阻力开始显现之前的热情开始退潮内容也从“干货爆炸”变成了“乏善可陈”于是很多人就默认“这件事不适合我”悄悄弃坑。所以这篇“学习日志2”我不打算写成那种“今天我学了XXX感觉收获满满”的流水账。我想把它当成一次真实的实验记录聊聊当新鲜感退去之后我是靠什么把学习这件事续下来的以及在这段时间里踩过的坑、验证过的工具、整理出的一套能直接复用的方法。这篇内容适合正在坚持某类技能学习的人看不管是编程、语言、考研还是健身核心逻辑是通用的。如果你正卡在“学了几天提不起劲”的阶段这篇应该能帮上忙。1. 为什么你写不到“第二篇”就放弃了1.1 新鲜感曲线的陷阱几乎所有学习计划都逃不过一条曲线兴奋期第1-3天- 疲软期第4-7天- 习惯期第8天以后。“第二篇日志”恰好落在疲软期的尾巴上这个位置极其尴尬——第一篇积累的素材已经用完新知识还没形成体系想写点干货却发现自己连个像样的总结都凑不出来。我前几次失败的学习尝试死因高度一致一开始给自己定了每天2小时的硬指标第一周完成了第二周某天因为加班、聚会、单纯犯懒等任何原因断了一天然后整个计划就像多米诺骨牌一样塌了。后来我换了个思路。不再要求自己“每天必须写日志”而是改成“每次学完必须留下痕迹”。痕迹可以是一个代码片段、一张思维导图、三个问题甚至只是重新整理过的几个快捷键。这个改动看似不起眼却直接把触发条件从“意志力驱动”变成了“动作驱动”。1.2 第二篇日志的正确用法学习日志的本质不是“日记”而是“复盘工具”。第二篇尤其如此它是你调整方向、修正方法的最佳时机。第一篇发现的问题第二篇要去验证解决方案第一篇没来得及整理的细节第二篇要补全。我的第二篇日志结构通常是固定的三块这周实际学了什么和计划对比找出偏差哪些方法被证明是无效的及时止损下周准备怎么改具体的、可执行的动作不要小看这个看似简单的结构。它逼着我把“感觉”变成“事实”。比如我发现“边看视频边敲代码”这个方法对我完全无效因为注意力会被视频节奏带着跑代码敲完了脑子却没跟上。换成“先看完一个章节再合上视频自己写一遍”之后效率提升了不止一倍。1.3 给“第二篇”定一个硬性底线如果你现在正准备开始写自己的第二篇学习日志我建议你给自己定一条底线这一篇必须包含一个可复现的成果。什么叫可复现的成果不是“我理解了XXX”而是“我做出了XXX”。拿我学爬虫举例第一篇日志写的是“我理解了requests库的基本用法”第二篇写的则是“我成功抓取了豆瓣电影Top250的前50条数据并保存成CSV”。前者是想法后者才是作品。有了这个底线学习日志就不再是自我安慰的工具而是实打实的进度凭证。你在写第二篇的时候会本能地逼自己去做点能写进日志的东西而不是坐在那儿“学习”了三天却什么都没产出来。2. 踩坑复盘那些让我绕了近一周远路的问题2.1 坑一工具党心态装了一圈又卸了进入爬虫学习后的第一个大坑就是工具选择焦虑。网上的教程各有各的偏好有的推荐Anaconda有的推荐纯Python加pip有的说VSCode够用有的说他用PyCharm写了五年。我差点把所有编辑器都装一遍最后折腾了半天环境变量一无所获。后来我明白了一个道理工具是为流程服务的不是为仪式感服务的。一个新手在学习初期最需要的是“打开就能写、写完就能跑”的极简工具链。Anaconda自带Python解释器和Jupyter Notebook装上即用对于新手来说远比自己配pip、venv、IDE要省心得多。等到了需要部署项目、管理复杂依赖的阶段再迁移到更工程化的工具不迟。所以我最终的方案是Anaconda做环境管理命令行用自带的终端调试代码用Jupyter Notebook。轻量、直接、没有多余环节。2.2 坑二贪多嚼不烂同时开了太多条线这大概是所有自学者的通病。我刚开始学爬虫的时候同时在看HTML教程、CSS教程、Python基础课、正则表达式文档还下载了两本PDF。结果一周下来每条线都只学了个开头脑子里一团浆糊。学到中期我终于想通了给自己砍掉了一大半内容只保留一条主线用requests抓取网页-用解析库提取数据-存成文件。HTML和CSS只学到能看懂结构就够了正则表达式只学到能匹配自己想要的数据就够了其他的全部延后。这种“窄带学习”看似笨拙实际上极其高效。因为攀爬任何一个陌生领域最忌讳的就是同时平行推进多条知识线。正确的姿势是先把最小闭环跑通再往里面补细节。2.3 坑三笔记只收藏不加工我之前有个坏习惯遇到好文章就复制粘贴到笔记软件里收藏完就当学过了。但事实是收藏的内容如果不进行加工一周后连标题都想不起来。这回我改变了策略。每次学完新知识点我强制自己在当天把笔记重写一遍不用原文而是用自己的话描述。碰到讲不清楚的地方就说明没真正理解必须回头再看。这个过程有点费时间但效果拔群——知识点不再只是“过眼”的东西而是变成了自己的东西。3. 第一个爬虫项目的实操记录豆瓣电影Top2503.1 项目目标与思路选豆瓣电影Top250作为第一个练手项目是深思熟虑后的选择。这个页面结构稳定、没有复杂的登录机制、数据量适中250条非常适合用来跑通“请求-解析-存储”的最小闭环。先明确目标抓取每部电影的排名、片名、导演、评分和一句经典台词存到CSV文件里。这个目标不大不小既能覆盖核心知识点又不会让人在中途因为过度复杂而放弃。整体流程分为四个步骤发请求获取网页源码、解析HTML提取数据、清洗数据格式、写入CSV文件。3.2 请求模块的实现与细节先写最基础的请求代码用requests库抓取第一页数据import requests url https://movie.douban.com/top250 headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } response requests.get(url, headersheaders, timeout10) response.encoding utf-8 print(response.status_code) print(response.text[:500])这里有几个细节必须注意都是踩坑换来的教训User-Agent一定要设置。豆瓣对没有浏览器标识的请求相当敏感不带UA很容易直接返回418错误码。我最初测试时就是忘了加上结果打印了一堆乱码和错误信息排查了半天才发现是这个原因。encoding要显式指定。虽然requests库会根据响应头做编码推断但偶尔会猜错。显式指定utf-8可以有效避免中文乱码。加timeout。网络请求是不可控的如果没有超时限制程序会在遇到无响应时一直卡住特别是后面要跑循环抓取250条数据时这个参数直接决定了程序是健壮还是脆弱。3.3 解析模块用一个小众但好用的库解析HTML有多种选择正则表达式、BeautifulSoup、lxml、parsel等。我最终选了parsel这个库原因有三点第一它的语法和CSS选择器语义高度一致学过前端的人几乎零成本上手第二它内置了XPath和正则两种补充方案兼容性极强第三运行速度比BeautifulSoup快很多数据量大时优势明显。import parsel selector parsel.Selector(response.text) # 观察HTML结构后发现每条电影信息都放在 .item 这个div里 items selector.css(.item) for item in items: title item.css(.title::text).get() rating item.css(.rating_num::text).get() quote item.css(.quote span::text).get() print(title, rating, quote)这里我特别想说一下这个::text的写法。很多新手会在选择器后面直接用.get()但如果没有::text这个伪元素拿到的是整个子元素的HTML内容而不是纯文本。别小看这个细节它对后续数据清洗的影响非常大。3.4 翻页处理的几种方案豆瓣Top250一共10页每页25条地址规律是?start页码*25。处理翻页的方式有几种第一种是直接拼接URL简单粗暴第二种是使用requests的params参数由库来处理编码问题更规范。我用了第二种for page in range(10): params {start: page * 25, filter: } response requests.get(url, headersheaders, paramsparams, timeout10) selector parsel.Selector(response.text) # 解析逻辑...每次都重新发一次请求这在大数据量场景下不够高效但对于250条数据来说完全够用而且程序结构更清晰。3.5 数据存储与完整代码最后把数据存成CSV文件import csv with open(top250.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([排名, 片名, 评分, 台词]) for page in range(10): params {start: page * 25, filter: } response requests.get(url, headersheaders, paramsparams, timeout10) selector parsel.Selector(response.text) for item in selector.css(.item): rank item.css(.pic em::text).get() title item.css(.title::text).get() rating item.css(.rating_num::text).get() quote item.css(.quote span::text).get() writer.writerow([rank, title, rating, quote]) print(f第{page 1}页完成)这里有个国人特别容易踩的坑CSV文件用Excel打开会乱码原因在于编码格式。解决方案就是上面代码里写的encodingutf-8-sig这个编码格式会在文件开头写入BOM标记Excel识别后就能正确显示中文了。这个小知识点看似不起眼但如果不说出来至少有一半照着教程写代码的人会在这里卡住然后怀疑是自己的代码写错了。4. 遇到过的常见问题和排查技巧4.1 返回418状态码不是封你是防你有段时间豆瓣会对某些请求返回418状态码。很多新手看到418就慌了以为自己的IP被拉黑了。其实418的意义是“我是茶壶”网站借此表明“我不想让你访问但也不想明说你被拉黑”。最常见的触发原因就是请求头没有伪装。解决办法很简单把User-Agent设置成真实浏览器的完整值最好再加上常用的Accept-Language等请求头字段。如果还是被拦可以考虑降低请求频率在两次请求之间加一个随机延迟。import time import random time.sleep(random.uniform(1, 3))注意这个延迟上限不要设得太大否则250条数据跑起来会很慢。设置成1到3秒之间既不会让网站压力过大也能保证程序的完成速度在可接受的范围内。4.2 解析结果全是None先打印再动手调试解析代码时最痛苦的情况就是程序不报错但所有字段都是None。这种时候不能用猜的要先把中间产物打印出来看。我的调试节奏是先print(response.text[:1000])看看网页源码有没有正常获取再print(selector.css(.item).getall())看看选择器有没有匹配到内容最后再看字段级的选择器。一步一验证很快就能定位问题。有一次我的选择器写得没问题却一直匹配不到内容最后发现是因为页面结构里有嵌套的class一个更粗粒度的选择器把整个大块匹配掉了导致子选择器全都失灵。这个问题如果不打印中间结果光靠脑袋空想根本发现不了。4.3 超时问题给网络请求上一道保险爬虫跑着跑着突然卡住不动多半是某个请求挂起了。加了timeout10参数之后每个请求超过10秒就会抛超时异常程序不会无限等待。进阶一点的做法是配合try-except做重试def fetch_with_retry(url, headers, max_retries3): for i in range(max_retries): try: response requests.get(url, headersheaders, timeout10) return response except requests.exceptions.RequestException: print(f第{i 1}次请求失败正在重试...) time.sleep(2) return None这段代码引入了一个很实用的思想不是所有请求都会一次成功与其让整段程序崩掉不如给它几次重试的机会。这在真实的爬虫工程里几乎是标配。4.4 数据清洗别急着往文件里写我第一版代码跑出来的CSV文件里片名那一列有些长这样肖申克的救赎\n导演: 弗兰克·德拉邦特仔细看才能发现是选择器匹配到了多个元素的文本中间用换行拼到了一起。解决办法是清洗数据把空白字符替换掉去掉多余内容。或者更精确地控制选择器只匹配想要的那一个title节点。类似这种问题如果数据量小还能手工修如果数据量大了就必须在写文件之前做好清洗否则后期治理数据的成本远超你当初存数据的时间。5. 学习日志的模板整理与方法论沉淀5.1 我现在用的日志模板这套模板是我折腾了三版之后定下来的分享出来给有需要的朋友做参考本周主题一句话说清楚这周在学什么完成情况列出了任务和实际完成度用百分比标注核心收获写出3个“以前不知道现在知道了”的知识点遇到的问题描述现象、排查过程、最终解法下周计划最多写3件事越具体越好这个模板的特点是把精力放在“问题”和“收获”上而不是花大量篇幅描述“我做了什么”。写日志的根本目的是给未来的自己看让那时的自己能一秒钟定位到当时卡住的地方。5.2 费曼技巧在学习日志中的实践有一种方法我觉得特别适合配合学习日志使用——费曼技巧。简单说就是在日志里把当天学到的知识点用大白话写一遍假装自己在给一个完全不懂的人讲这个东西。比如我学XPath时给自己写的一段话版本是“XPath就是给HTML写地址的方法。你想找哪个元素就写它从顶到下的路径。比如表格里第二行第三个单元格就是一种路径写法。CSS选择器是用属性来找元素XPath是用位置关系来找元素两者各有各的场景。”这样写的好处是当你试图把知识讲得足够简单时就会倒逼自己把模糊的地方弄明白。那些讲不顺的部分就是你还没真正学会的部分。5.3 让兴趣和进度形成正反馈坚持写学习日志最难的地方在于正反馈太慢。尤其到了第二阶段知识难度上来了产出的作品却还很稚嫩很容易让人产生“这么努力有什么用”的怀疑。我的解决办法是把目标切小。不要求一个月精通爬虫只要求今天写出一段能运行的代码不要求做出完整的项目只要求把上一页学会的选择器语法用熟。这些微型目标的难度低到了“不可能失败”的程度而每次“完成了”的感觉都会给大脑一个正反馈信号。积累下来的反馈多了你就会发现不需要靠意志力也能推进。学习不再是咬牙坚持的事而变成了每天顺手完成的事。6. 一些想直接告诉你的心得说实话这个爬虫项目本身并不复杂。豆瓣Top250这个页面老实讲也是教科书级别的“过于友好”网上随便一搜就是一大堆参考代码。但我依然觉得把这一个项目从头到尾写完、调通、踩过那一圈坑远比看十篇别人的教程更有价值。因为我真正学到的不是那几个函数的用法而是一套解决问题的思路遇到报错先读提示不要急着怀疑人生遇到奇怪的结果先打印中间数据不要凭空猜测学到新知识先用自己的话复述一遍给自己制造“讲给别人听”的状态。这套思路跟具体的技术栈无关换到任何学习领域都管用。我最近在用它学一些新的东西效果也很稳定。所以这篇“学习日志2”看似记录的是爬虫基础实际上记录的是我从“靠热情驱动学习”转换到“靠方法驱动学习”的那段过程。最后分享一个让我一直受益的小习惯每篇日志的结尾我都会给自己写一句“下次怎么看这篇日志”——有时候是提醒自己在做项目前先翻翻对应章节的目录有时候是告诫自己别重复踩已经踩过的坑。把日志当成能对话的朋友来写而不是当成任务来交差坚持下来的概率会大很多。