web开发技术课程设计这门课，发技我印象最深的术课是那个“在线二手书交易平台”。组里五个人，程设四个人在划水，发技只有我和另一个女生在GitHub上疯狂提交代码。术课那种感觉，程设就像一个人扛着一根巨大的发技木头在跑，后面四个人只是术课扶着木头假装用力。

课程设计的程设核心不是让你学会某个框架，而是发技逼你在一个真实的、有截止日期的术课项目里做取舍。我们最初想用React做前端，程设Node.js做后端，发技MongoDB存数据。术课但到了第二周，程设发现连登录注册都搞不定——不是技术不会，而是需求没想清楚。比如，用户上传的书籍图片到底要不要压缩？搜索结果按什么排序？这些问题在文档里写“待定”，到了代码里就变成无穷无尽的if-else。

后来我们砍掉了一半功能，只保留发布、浏览、私信和订单确认。我负责写商品列表页，用最简单的fetch请求后端API，渲染卡片。结果第三天就踩了跨域问题的坑。浏览器报错CORS，后端同学说“我加了cors中间件啊”，我这边刷新十次还是红字。最后发现是端口写错了——他监听在3001，我请求的是3000。这种低级错误，教科书里不会写，但每个做过课程设计的人都会心一笑。

到了中期答辩，老师问了一个特别刁钻的问题：“如果用户同时打开两个标签页，都提交了同一个订单，你怎么处理？”我们愣住了。后端只做了简单的库存判断，根本没考虑并发。老师没批评，只说了一句：“你们课设能跑，但离能上线还差一个量级。”这句话让我后来在实习面试时特别受用——当面试官问“如何防止重复提交订单”，我能立刻讲出那次失败的经历。

最让我意外的是，课程设计结束后，那个划水的同学居然主动来问我能不能把代码给他“学习一下”。我给了，但把数据库密码改了。不是因为小气，而是他连我们用了什么ORM都不知道，拿去交差只会暴露更多问题。后来他在朋友圈晒了优秀课设的截图，配文“团队合作的力量”。我没点赞，也没拆穿。

如果你现在要选课程设计的题目，我建议别做那种烂大街的“图书管理系统”或“学生选课系统”。做点有真实痛点的东西，比如“宿舍楼道报修小程序”或者“社团活动签到工具”。哪怕功能简单，但只要你能说出“这个设计是为了解决什么实际问题”，答辩时老师就会觉得你有思考。技术栈反而不重要，我们组用的React和Express，隔壁组用Vue加Flask，分数一样高。

最后说个细节。提交代码那天，我们把所有console.log都删掉了，唯独漏了商品详情页里一行“console.log('用户点进来了', Date.now())”。后来我打开线上演示环境，看到那行日志在控制台里跳动，突然觉得这个课设就像这行日志——它不完美，甚至有点笨拙，但那是我们一行行写出来的，每一个报错都对应着一个熬夜的夜晚。这大概就是课程设计的意义，不是让你成为全栈大神，而是让你知道，一个东西从0到1跑起来，中间有多少脏活累活。