“Day3”这个标题我是从一场30天挑战里带出来的。那是我给自己定的任务30天从零做一个小工具每天记录进度、结果和踩过的坑。而第3天恰恰是整个周期里最微妙也最容易翻车的一天——Day1你靠新鲜感撑着Day2还斗志昂扬到Day3热情开始退潮真实的技术问题开始露头也是最容易劝退的一天。如果你正因为某个计划、某个项目、某次打卡而搜索“Day3”大概率你也处在类似的节点上。这篇博文就是我Day3的完整实操记录在24小时内把一个“数据看板”从零跑到第一个可用版本——后端接口、前端页面、趋势图表全部打通。它适合所有想动手做点什么、却总在第三天前后放弃的朋友尤其是想学点真东西的初级开发者。1. Day3的挑战定位与整体思路1.1 为什么是30天挑战Day3意味着什么30天挑战在编程圈、写作圈、健身圈都很流行但真正走完的人永远是少数。大多数人的放弃点就集中在Day3到Day7之间。原因不难理解前两天你还在“计划”和“调研”的舒适区里做的都是相对安全的动作而到了第三天你必须从“准备”切换到“产出”第一次直面“我做的东西到底行不行”的拷问。这个切换带来的挫败感比想象的猛烈。我当时发起的挑战是30天从零做一个“个人数据看板”。起因很简单我自己在各平台发内容数据分散在后台里每次想看趋势都非常麻烦干脆写一个聚合页面把关键指标集中展示。Day1我做的是需求边界到底看哪些指标不做哪些功能。Day2做的是技术调研用什么语言、什么框架、什么图表库。Day3就是动手日——正好处于“理论知识已经够了再不动手就会烂尾”的临界点。所以Day3的本质不是“挑战的第三天”而是“计划到执行的第一天”。它必须有一个硬性交付物哪怕再丑、再简陋也要让项目从“脑子里”变成“屏幕上”。我在这一天给自己定的规矩只有一条今天结束之前必须看到一个能自己跑起来的网页网页里必须有一个有数据的图表数据必须来自自己写的后端接口。mock数据可以假数据没问题但整条链路必须是真的。1.2 Day3要交付什么一个可运行的最小闭环很多人项目烂尾不是死在功能复杂而是死在第一天就想做完整产品。Day3最忌讳的就是给自己列一个庞大的需求清单。我的做法是反向操作砍到只剩一个最核心的闭环。我Day3的交付目标拆开就四件事后端服务能启动提供一个返回趋势数据的接口。前端页面能打开在浏览器里渲染出一个折线图。数据是mock的但必须符合“访问趋势”的基本规律看着像真的。整个项目能跟随代码修改自动刷新方便后续迭代。为什么执着于“闭环”因为技术风险越早暴露越好。你要是在第三天就把后端、前端、数据格式全打通了后面即便遇到坑也都是单个点的问题但你如果第三天还在搭目录结构、配数据库、做用户权限那真正的问题会一直积压到第六七天集中爆发。到那时候你面对的就不是一个bug而是一团乱麻。我后来复盘时意识到Day3最值钱的产出其实不是那几十行代码而是“我知道这项目能跑起来”的确定性。这份确定性带来的正反馈比任何计划表都管用。它让我在第四天、第五天遇到难题时有底气告诉自己管道已经通了剩下的只是往里面填东西。2. 动手前的技术选型与准备2.1 为什么选这套组合FastAPI SQLite ECharts 原生HTML技术选型这件事特别容易陷入“选择困难症”。市面上光是Python后端框架就有FastAPI、Flask、Django前端更有React、Vue、Svelte一堆选项。我的建议是单人小项目Day3这种节点永远选“当天能跑通”的组合而不是“未来最强大”的组合。这就像装修房子第三天你该做的是把水电管道打通而不是纠结要不要装地暖。我最终敲定的组合是后端FastAPI。理由很直接它自带API文档接口写完浏览器打开/docs就能调试省掉手工写接口说明和用Postman的步骤。而且基于类型注解的请求校验非常省事几乎不用写防御代码。相比Flask少写很多样板代码相比Django轻量太多没必要为一个单页看板背一个重型框架。数据库SQLite。这是Python内置的零安装、零配置一个文件就是一个库。对于个人看板这种低并发的场景完全够用。我不需要单独装数据库服务也不用记账号密码数据导出就是拷贝一个文件省心。图表库ECharts。功能强、例子多、折线图十几行就能出效果而且从官网下个echarts.min.js放到本地静态目录就能用不需要引入Node.js构建工具链。前端原生HTML JavaScript。不引入React、Vue因为我的页面只是一个图表加几块面板用框架只会增加心智负担和构建步骤。这套组合还有一个隐藏优点所有依赖加起来就两三个Python包加一个JS文件安装时间极短非常契合Day3“快速见效”的定位。如果某天看板功能复杂到需要React我完全可以到时候再重写前端那都是后话。2.2 Day3当天的环境初始化清单开始写代码之前我先把环境拉起来。别小看这一步很多人的时间就是浪费在“环境不对、包装不上、版本冲突”这些地方。我的初始化步骤记录如下# 1. 创建项目目录 mkdir day3_dashboard cd day3_dashboard # 2. 创建Python虚拟环境 python3 -m venv venv source venv/bin/activate # Windows下是 venv\Scripts\activate # 3. 安装FastAPI和Uvicorn pip install fastapi[all] # 4. 基础验证 python -c import fastapi; print(fastapi.__version__)这里解释两个关键点。第一为什么要用虚拟环境因为Python项目非常容易互相污染尤其是你同时维护多个项目时A项目升级的依赖可能直接搞挂B项目。虚拟环境就是给每个项目一个独立的“运行小房间”互不影响。第二为什么用fastapi[all]而不是fastapi这个带[all]的安装方式会把Uvicorn、Pydantic、Jinja2等一系列常用配套一起装上省去后续“缺哪个装哪个”的折腾。如果你介意装多余的东西也可以单独执行pip install fastapi uvicorn效果一样。目录结构我也顺手定好了day3_dashboard/ ├── main.py └── static/ ├── index.html └── echarts.min.jsmain.py放后端代码static放所有前端静态资源。为什么这么简单因为Day3不需要过度设计。我在项目初期刻意压制了建“models”、“routes”、“templates”这些目录结构的冲动——功能就一个接口目录建得再豪华代码还是那几十行。等第四天功能变多再拆结构会有更清晰的判断。2.3 一个值得养成的习惯先把调试口子留好正式写代码之前我建议你调整一个心态Day3的代码不是最终版本是“可运行的第一版”。所以不要追求优雅先追求“能看见错误”。我的具体做法是第一版接口不做任何异常处理让错误直接抛出来日志能打则打绝不吞异常。因为在这个阶段最大的风险不是程序崩溃而是程序“看似正常但数据是错的”。日志越直白排查越快。3. 核心环节实现从接口到图表3.1 第一步定义数据模型和Mock数据看板的第一张图我选了“站点访问趋势”这也是数据看板里最经典、最基础的一个指标。数据模型非常简单一条记录包含三个字段日期、PV页面浏览量、UV独立访客数。我要生成过去14天的mock数据但不能是纯随机数得让它看起来像真实的站点数据。真实数据有几个特点整体有缓慢增长趋势周中比周末高还有一定的随机起伏。我写了一个生成函数import random from datetime import date, timedelta def gen_mock(days14): data [] today date.today() for i in range(days - 1, -1, -1): d today - timedelta(daysi) # 周末流量略低整体呈缓慢增长 weekend_ratio 0.85 if d.weekday() 5 else 1.0 growth (days - i) * 0.4 pv int((100 growth) * weekend_ratio * random.uniform(0.9, 1.1)) uv int(pv * random.uniform(0.5, 0.65)) data.append({date: d.isoformat(), pv: pv, uv: uv}) return data很多人写mock数据就是random.randint(1, 100)这样生成的曲线图看起来像心电图毫无说服力。我这里故意加了三个小逻辑weekend_ratio把周末压低15%符合大多数站点的真实访问习惯growth让数值随天数递增模拟一个成长中的项目random.uniform(0.9, 1.1)在趋势上叠加10%的随机波动让曲线显得自然。至于为什么uv int(pv * random.uniform(0.5, 0.65))因为同一访问者一天会看多个页面UV通常比PV低比例在50%到65%之间是常见区间。这种细节是内行看门道的地方——哪怕mock数据也要为用户后面拿真实数据去对比时留有余地。3.2 第二步写第一个REST接口接口层我做得非常克制。只提供一个/api/trend返回上面的mock数据数组from fastapi import FastAPI from fastapi.middleware.cors import CORSMiddleware app FastAPI(titlePersonal Dashboard) app.add_middleware( CORSMiddleware, allow_origins[*], allow_methods[*], allow_headers[*], ) app.get(/api/trend) def get_trend(): return gen_mock()这里说明一个很多新手忽略的细节接口函数我用的是def而不是async def。因为gen_mock()是纯CPU计算没有等待数据库、等待外部请求这种IO操作用普通def就足够了。FastAPI遇到普通def会自动把它扔到线程池运行不会阻塞事件循环反而更简单可靠。只有当你确实写await语句时才需要async def。CORS中间件我加上是有原因的。虽然现在页面和后端是同源的但浏览器对跨域请求有严格的同源策略限制。如果第四天我把页面和接口拆到不同端口或者直接用file://协议打开HTML文件没有CORS配置就会报错。为了后面少踩一个坑我Day3就先把这个配置写上。allow_origins[*]表示允许任何来源这个配置在开发阶段足够安全等正式部署上线时再收紧。启动服务也很简单uvicorn main:app --reload --port 8000--reload是开发模式必备它监听代码文件变化修改后自动重启服务不用手动停掉再启动。启动后浏览器访问http://127.0.0.1:8000/api/trend就能看到一长串JSON数据。接着访问http://127.0.0.1:8000/docs会看到一个自动生成的交互式API文档页面每个接口的参数、返回值都列得清清楚楚甚至可以直接在页面上调用。这一点是FastAPI比Flask舒服太多的地方——调试接口几乎不用打开Postman。3.3 第三步前端页面搭建与ECharts接入后端接口通了剩下就是前端展示。我在static/index.html里写一个非常朴素的页面一个标题、一个图表容器、一段JavaScript。ECharts的使用方式分三步初始化实例、配置setOption、把VUE……不对把数据填进去。!DOCTYPE html html langzh-CN head meta charsetUTF-8 title个人数据看板 - Day3/title script src/echarts.min.js/script style body { font-family: system-ui; background: #f7f7f7; margin: 0; } h1 { text-align: center; margin-top: 40px; color: #333; font-size: 24px; } #chart { width: 900px; max-width: 90%; height: 450px; margin: 20px auto; background: #fff; border-radius: 10px; padding: 10px; } /style /head body h1站点访问趋势 · Day3 预览/h1 div idchart/div script const chart echarts.init(document.getElementById(chart)); fetch(/api/trend) .then(res res.json()) .then(rows { if (!rows.length) { document.getElementById(chart).innerHTML p styletext-align:center;color:#999;line-height:450px暂无数据/p; return; } chart.setOption({ tooltip: { trigger: axis }, legend: { data: [PV, UV] }, grid: { left: 60, right: 40, top: 50, bottom: 40 }, xAxis: { type: category, data: rows.map(r r.date) }, yAxis: { type: value }, series: [ { name: PV, type: line, smooth: true, areaStyle: { opacity: 0.1 }, data: rows.map(r r.pv) }, { name: UV, type: line, smooth: true, data: rows.map(r r.uv) } ] }); }) .catch(err console.error(加载失败, err)); /script /body /html前端逻辑不复杂但要解释一个关键设计数据是从/api/trend通过fetch动态获取的。这意味着后端加上新的字段、改成真实数据前端只要字段名不变就完全不用改动。这就是前后端分离的基本思路——API是契约两边各自演进。到这里后端main.py还要补一个挂载静态目录的步骤。我一开始忘了加结果访问根路径直接404。配置是这样的from fastapi.staticfiles import StaticFiles import os app.mount(/, StaticFiles(directorystatic, htmlTrue), namestatic)htmlTrue的意思是当访问/时直接返回static目录下的index.html。这样浏览器打开http://127.0.0.1:8000/就能看到完整的图表页面。因为前端脚本里加载ECharts的路径是/echarts.min.js正好对应static目录下的同名文件。最后效果就是打开页面看到一条带阴影的PV趋势线和一条UV趋势线鼠标悬停会显示对应日期的数值。虽然是mock数据不过整条链路从浏览器到后端再到数据生成完全真实。4. Day3现场实录我踩过的坑和排查过程4.1 端口被占用与热更新不生效Day3当天我碰到的第一个问题启动Uvicorn时报端口被占用。这情况太常见了——有些程序会悄悄占用8000端口或者你之前启动的服务进程没关干净。排查命令我现在已经背下来了# Linux/macOS lsof -i :8000 # 或者在Linux下 ss -tlnp | grep 8000找到占用端口的进程PID之后要么kill -9 PID结束掉要么干脆换一个端口比如Uvicorn启动时加上--port 8081。我当时的策略是直接换端口因为那个占用端口的进程可能是其他重要服务硬杀不安全。换个端口对本地开发没有任何影响前端页面的请求路径也没把端口写死在代码里所以零成本。第二个坑是--reload热更新失效。我明明改了代码浏览器刷新页面却还是旧数据。排查半天发现Uvicorn的--reload在部分系统上对文件事件监听的响应有延迟尤其是当你用某些编辑器比如Vim、部分远程编辑方式保存文件时触发的事件类型可能不被识别。解决方式很粗暴看控制台有没有出现“Reloading...”的字样如果没有手动CtrlC重启一下服务。别在热更新这件事上死磕重启最多三秒钟但你要是怀疑半天半小时就没了。4.2 CORS、日期序列化与根路径404遇到跨域问题是在我直接用浏览器打开本地HTML文件以file://开头调试的时候。控制台红色报错写着No Access-Control-Allow-Origin header is present on the requested resource这个报错很经典。浏览器出于安全策略默认不允许网页从一个来源去请求另一个来源的数据。我当时的“网页来源”是file://后端来源是http://127.0.0.1:8000两个来源不一样触发了同源策略。解决之道有两个一个是像我在main.py里那样加CORS中间件另一个更省事的方式——不要用file://打开页面而是通过http://127.0.0.1:8000/访问。后者属于同源访问根本不会触发跨域。我两个都用了配置写上是给后续埋保护日常调试则统一走HTTP地址。关于日期序列化我也记下一笔。我mock数据用的是d.isoformat()写死了字符串格式所以接口返回的是正常的2025-01-07。但如果哪天你直接返回一个datetime对象FastAPI默认序列化出的格式是带时区和毫秒的比如2025-01-07T00:00:0008:00这在你展示图表时就需要额外处理。为了避免这个坑建议在数据模型层就把日期统一成YYYY-MM-DD字符串。最后是根路径404。这个坑特别隐蔽因为我一开始只写了/api/trend接口没挂载静态目录。结果接口通但打开http://127.0.0.1:8000/显示404。这不是FastAPI的问题而是我没配。加了app.mount(/, StaticFiles(...))后一切正常。注意挂载静态目录的动作要放在定义接口之后否则它会拦截掉所有路由导致/api/trend也404。4.3 空数据态与首屏加载体验还有一个容易被新手忽略的细节图表空数据态的兜底。mock数据一定有内容但因为前端是异步加载的如果后端接口报错、数据返回空数组或者接口还没返回时页面上就会出现一个空白的图表区域用户看着就像系统崩了。我在前端代码里加了两个处理一是在请求未完成时显示一个简单的加载文字二是在数据为空时显示“暂无数据”的占位。实现方式就是判断rows.lengthif (!rows.length) { document.getElementById(chart).innerHTML 暂无数据; }别看这条代码简单它保证了你后面接真实数据时哪怕早期阶段数据库里没数据页面也不会白屏。这个习惯非常值得保持任何依赖后端数据的页面都要先想好“空的时候长什么样”。5. Day3复盘这一天留下的经验比代码更值钱5.1 最小闭环为什么这么快见效Day3实际用时大约4小时比预期还快。我认为核心原因是“目标控制”做得好。写作一整天代码的过程中我反复问自己的只有一个问题这个环节对“今天看到一个有数据的图表”有贡献吗没有贡献的一律不做。比如我没有配置数据库连接因为mock数据是函数生成的用不上数据库没有做用户登录因为单人看板不需要没有写中英文双语文案因为那不是现在的问题。这种“无情砍需求”的魄力是推动项目的第一步。如果你也卡在某一天的项目进展上我强烈建议你找出当前最大的那个障碍只解决它别的先放一边。5.2 三天养成的两个实用习惯连续写了三天代码我沉淀了两个非常实在的习惯。第一个习惯是每天收工前在项目根目录的TODO.md里写三行——今天完成了什么、今天卡住了什么、明天第一步做什么。尤其是“今天卡住了什么”这一条价值极大因为第二天开工时你往往是大脑最清醒的时候盯着昨天记录的那个卡点直接攻效率最高。第二个习惯是把TODO只当记录不当KPI。我见过太多人用计划表管理项目结果被计划表压垮每天都在“补昨天的进度”。我更倾向于把计划当成一个念头记录本而不是承诺书。今天做不完就顺延关键是每天都保持产出哪怕只有一小步。5.3 Day3之后的规划方向Day3完成的最小闭环给后续铺了一条清晰的路。按我当时的排期后面几天的计划大致是这样天数目标具体内容Day4接真实数据从各平台后台导出CSV写解析脚本导入SQLiteDay5加第二个图表增加“来源渠道占比”饼图扩展API字段Day6页面美化调整配色、卡片布局、响应式适配Day7部署上线在服务器上用进程守护方式跑起来所有人可访问这张表透露一个核心策略每一个后续任务都建立在上一个已完成的基础上。Day4的“接真实数据”依赖Day3的“有接口”Day5的“第二张图”依赖Day4的“数据入库”。这种逐层递进的方式让每一天都像是前一天的自然延伸不会出现“突然需要重写整个架构”的绝望时刻。我个人在Day3结束后最大的体会是第三天的意义不在于代码本身而在于它验证了一件事一个看起来不小的项目其实可以用一天时间先跑出一个粗糙但完整的版本。这种经验会改变你面对所有长期任务的心态——你不用再害怕开始因为你知道最难的不是把东西做完美而是让第一个版本活起来。如果你也正好在某个挑战的第3天别急着否定自己也别纠结方案不够完美。先把那个最小闭环做出来后面的事我们边做边聊。