很多同学在毕业设计里只关心功能是否跑通，等到测试时才发现数据量一上来页面就卡、接口超时。算法复杂度分析正是提前发现这类问题的工具，它不需要复杂设备，只需要在写代码前对运算量级有个判断。哪怕你做的只是一个课程管理或图书借阅系统，弄清楚每个操作随数据规模增长的变化趋势，也能让系统在答辩演示时保持流畅。
分析时可以从三个角度入手：一是渐进复杂度，用大O表示最坏情况下的增长趋势，重点关注循环嵌套、递归深度和集合查找；二是空间复杂度，留意一次性把所有数据读进内存的写法；三是平均与最坏情况的区别，例如哈希表查询平均很快，但冲突严重时性能会退化。论文中不必堆砌公式，能把关键函数的时间复杂度说清楚即可。
定位真实瓶颈要靠测量而不是凭感觉。可以做规模递增实验，把数据量从一百条增加到一万条，记录响应时间的变化曲线；也可以用语言自带的性能分析工具找出耗时最多的函数。常见瓶颈集中在数据库的循环查询、重复计算、字符串拼接、缺少索引以及接口返回过多字段。
发现瓶颈后就进入取舍阶段。用缓存换时间、用空间换时间、用近似结果换精度，都是常见做法，但每种做法都要说明代价：缓存会带来一致性问题，预计算会占用存储并增加更新成本，近似算法会损失准确度。在论文中把取舍理由写清楚，比单纯写“优化后速度变快”更有说服力。
写作建议是把优化前后的数据整理成小表格，注明测试环境、数据规模和统计方式，并说明哪些优化是结构性的、哪些只是参数调优。答辩时如果被问到“数据量再大十倍会怎样”，能说清哪一部分会先撑不住，就已经很好了。