作为一名软件工程专业的学生毕业设计是检验我们学习成果和工程能力的重要一环。对于前端方向的同学来说选一个好题目至关重要太简单了显得没技术含量太复杂了又容易在有限的时间里“烂尾”。我自己在做毕设时也纠结了很久最后选择并完成了一个“可扩展的 Todo 应用”感觉收获特别大。今天就把我的思路、实现和踩过的坑都分享出来希望能给学弟学妹们提供一个清晰、可落地的参考方案。1. 前端毕设的常见痛点与破局思路在开始动手之前我们先分析一下大家做前端毕设时容易遇到的问题这样我们的方案才能有的放矢。技术堆砌缺乏深度很多同学喜欢把各种新技术名词如微前端、WebAssembly、Three.js都塞进项目里但每个都只是浅尝辄止没有深入理解其原理和最佳实践。这会导致项目看起来很“炫”但代码结构混乱经不起推敲。缺乏工程规范项目可能功能都实现了但代码风格不统一、没有模块化、缺少必要的注释和文档、也没有任何测试。这完全不符合“软件工程”的要求体现不出我们作为工程专业学生的素养。可维护性与扩展性差代码“写死”的情况很多状态管理混乱组件之间耦合严重。导师如果问“如何增加一个标签分类功能”可能就需要大改特改这直接暴露了设计上的缺陷。忽视非功能性需求只关注功能实现不考虑性能如长列表渲染、安全性如用户输入过滤、错误处理和数据持久化等项目显得很“玩具”。破局思路选择一个看似简单如Todo但内涵丰富的核心模型然后围绕它系统地实践前端工程化的各个环节。我们的目标不是做一个功能最花哨的Todo而是做一个代码结构最清晰、最健壮、最易于扩展的Todo应用。这更能体现我们的工程能力。2. 技术栈选型为什么是 React TypeScript市面上主流框架是 Vue 和 React。对于毕设而言两者都能做出优秀的项目。我选择 React TypeScript主要基于以下几点考量生态与就业市场React 在国内外的企业级应用中占有率非常高社区生态极其丰富。掌握 React TS 的技术栈对后续求职有直接帮助。类型安全与开发体验TypeScript 的静态类型检查能在编码阶段就发现很多潜在错误这对于构建可维护的中大型应用至关重要。它强迫我们思考数据的结构和接口本身就是一种很好的工程设计训练。学习曲线与扩展性Vue 的 API 设计更亲和上手更快。React 则更偏向函数式编程理念概念上可能需要更多时间理解如 Hook、不可变数据但一旦掌握其组合性和灵活性极高对于构建可扩展的应用模型非常有利。我们的“可扩展”目标与 React 的设计哲学很契合。工程化配套成熟React 社区在状态管理Redux, Zustand, Recoil、测试Jest, React Testing Library、构建工具Webpack, Vite等方面有非常成熟和多样化的解决方案方便我们按需集成体验完整的工程链路。结论对于旨在展示工程能力、并希望技术栈有长期价值的毕设React TypeScript 是更优选择。它能逼着我们写出更规范的代码这个学习过程本身就是毕设的重要收获。3. 核心实现细节从设计到代码确定了技术栈我们开始设计应用的核心架构。关键在于“解耦”和“清晰的分层”。数据模型设计 这是所有逻辑的起点。一个 Todo 项不仅仅是文本和完成状态。// types/todo.ts export interface ITodoItem { id: string; // 使用 uuid 或 Date.now() 生成避免用数组下标 title: string; completed: boolean; createdAt: number; // 时间戳用于排序 updatedAt: number; // 时间戳用于追踪变更 tags?: string[]; // 可选的标签为扩展留余地 } export type FilterType all | active | completed;组件分层设计 避免将所有逻辑堆在一个巨型组件里。我采用了常见的分层结构components/ui/纯展示型组件如Button,Input,Checkbox。只接收 props不关心业务逻辑。这便于复用和单独测试。components/features/功能型组件如TodoList,TodoItem,FilterBar。它们会调用自定义 Hook 来获取数据和操作函数。hooks/这是逻辑复用的核心。将数据获取、状态管理、副作用等逻辑封装成自定义 Hook。utils/工具函数如日期格式化、本地存储操作。services/如果后期接入真实后端 API这里放网络请求层。状态管理自定义 Hook 封装 对于 Todo 应用不一定需要 Redux。使用useState/useReducer配合 Context 或直接使用一个轻量级状态库如 Zustand即可。我选择用自定义 HookuseTodoStore来集中管理状态和逻辑实现业务逻辑与 UI 的解耦。// hooks/useTodoStore.ts import { useState, useCallback } from react; import { ITodoItem } from ../types/todo; import { todoStorage } from ../utils/storage; // 封装的 localStorage 操作 export const useTodoStore () { const [todos, setTodos] useStateITodoItem[](() { // 冷启动优化组件挂载时从 localStorage 初始化状态 return todoStorage.load(); }); const addTodo useCallback((title: string) { const newTodo: ITodoItem { id: todo_${Date.now()}, title: title.trim(), completed: false, createdAt: Date.now(), updatedAt: Date.now(), }; // 使用函数式更新避免依赖旧的 todos 状态 setTodos(prev { const newTodos [...prev, newTodo]; todoStorage.save(newTodos); // 同步持久化 return newTodos; }); }, []); // 依赖为空因为使用了函数式更新 const toggleTodo useCallback((id: string) { setTodos(prev prev.map(todo todo.id id ? { ...todo, completed: !todo.completed, updatedAt: Date.now() } : todo ) ); // 注意这里 setTodos 后状态是异步更新的。 // 持久化操作不能直接在这里用 todos而应该在 useEffect 中监听 todos 变化统一处理或者使用函数式更新并立即保存如上例。 }, []); // ... 其他操作如 deleteTodo, clearCompleted return { todos, addTodo, toggleTodo }; };数据持久化localStorage 的幂等写入与防抖 直接在每个操作里调用localStorage.setItem效率低下且不优雅。我们封装一个存储服务并注意幂等性多次操作结果一致和性能。// utils/storage.ts const STORAGE_KEY todos_app_data; export const todoStorage { load: (): ITodoItem[] { try { const data localStorage.getItem(STORAGE_KEY); return data ? JSON.parse(data) : []; } catch (error) { console.error(Failed to load todos from localStorage:, error); return []; // 出错时返回空数组保证应用可运行 } }, save: (todos: ITodoItem[]): void { try { // 幂等写入无论调用多少次只要输入相同存储的结果就相同。 // 使用防抖避免短时间内的频繁写入比如快速勾选多个todo localStorage.setItem(STORAGE_KEY, JSON.stringify(todos)); } catch (error) { console.error(Failed to save todos to localStorage:, error); // 可以在这里加入错误上报逻辑 } }, }; // 在 useTodoStore 中可以使用 useEffect 统一监听 todos 变化并防抖保存 import { useEffect } from react; import { debounce } from lodash-es; // 或自己实现一个简单防抖 // 在 hook 内部 useEffect(() { const saveDebounced debounce(() todoStorage.save(todos), 500); saveDebounced(); return () saveDebounced.cancel(); // 清理副作用 }, [todos]);4. 性能与安全性考量这部分是区分“玩具项目”和“工程化项目”的关键。性能列表渲染优化当 Todo 项很多时使用React.memo包装TodoItem组件避免不必要的重渲染。函数稳定性使用useCallback和useMemo缓存函数和计算值避免子组件因回调函数引用变化而重渲。虚拟滚动如果列表项极多成千上万可以考虑集成react-window或react-virtualized实现虚拟滚动。这在毕设中是一个很好的加分项。安全性XSS 防护React 默认会转义 JSX 中的变量这提供了基础防护。但如果我们使用dangerouslySetInnerHTML在 Todo 应用里通常不需要就必须对输入内容进行严格的消毒Sanitize。更常见的是在将用户输入的 Todo 标题存储或显示前可以进行简单的转义或过滤。避免内存泄漏在自定义 Hook 或组件中如果使用了事件监听器、定时器或订阅一定要在useEffect的清理函数中将其移除。5. 生产环境避坑指南基于我的实践分享几个容易出错的地方状态同步竞态Race Condition 在异步操作比如未来对接后端 API中如果连续快速触发“编辑-保存”后发的请求可能先返回导致状态被旧的响应覆盖。解决方案为每个请求生成唯一 ID如cancelToken在更新状态前检查当前请求 ID 是否匹配。路由懒加载配置错误 如果使用 React Router v6 做多页面并用React.lazy做懒加载以优化首屏切记Suspense 的 fallback 组件必须放在路由组件之上否则可能报错或白屏。// 正确示例 import { Suspense } from react; import { BrowserRouter, Routes, Route } from react-router-dom; const About React.lazy(() import(./pages/About)); function App() { return ( BrowserRouter Suspense fallback{divLoading.../div} Routes Route path/about element{About /} / /Routes /Suspense /BrowserRouter ); }TypeScript 严格模式 开启tsconfig.json中的strict: true。虽然初期会报很多错但它能帮你发现大量潜在的类型问题强制写出更健壮的代码毕设项目强烈推荐。单元测试集成 使用Jest和testing-library/react为关键工具函数和组件编写测试。不需要追求 100% 覆盖率但核心业务逻辑如todoStorage.save/load和自定义 Hook 的测试能极大提升项目质量并向导师展示你的工程素养。6. 总结与展望通过这样一个“可扩展的 Todo 应用”项目我们系统地实践了技术选型与论证React TS工程化项目结构分层、模块化状态管理与逻辑复用自定义 Hook数据持久化策略幂等、防抖性能与安全考量代码质量保障TypeScript、单元测试这个项目本身已经是一个完整、规范的毕设。但它的“可扩展性”意味着我们还能轻松地为其添加新功能比如标签系统为 Todo 添加分类。过滤器与搜索更复杂的数据查询。主题切换实践 CSS-in-JS 或 CSS 变量。后端接入将todoStorage替换为真实的 RESTful API 或 GraphQL 调用。最后的思考题如何将这个单机版 Todo 应用扩展成一个支持多人实时协作的 PWA渐进式 Web 应用这可能需要引入 WebSocket 进行实时同步使用 IndexedDB 进行离线存储并配置 Service Worker 实现离线可用和消息推送。这将是另一个充满挑战和学习的精彩项目。希望这篇笔记能为你提供一个清晰的前端毕设实现蓝图。记住好的毕设不在于想法多么新奇而在于如何用工程化的方法扎实地解决一个具体问题。祝你毕设顺利