简介这是一个基于Flutter/Dart开发的开源移动应用项目面向移动开发者与Flutter爱好者专门用于浏览e621与e926平台。它集成了帖子与图片池的搜索浏览、修图评论、图片下载上传、热门与收藏访问、标签关注、本地黑名单、DText文本解析、视频播放、自动更新检查以及多主题切换等二十余项功能完整覆盖了内容社区类App的常见业务闭环适合作为学习跨平台工程架构的参考样例。资源包共185个文件压缩后约29.59MB其中108个dart源文件构成主要业务逻辑与界面32个png和7个jpg提供图标与演示素材另有gradle、plist、storyboard、xcconfig等Android/iOS工程配置文件以及json、yaml、md等说明与依赖文件目录组织清晰能够帮助观察Flutter项目的模块划分与原生平台接入方式。目前已有3100人学习下载。通过剖析其中的帖子详情页、文本解析器、视频播放组件、设置面板与标签Wiki入口可以快速掌握Flutter下复杂列表交互、本地存储和网络请求的综合用法对开发或扩展此类移动应用有直接的参考价值。 “e1547”这个代号是我一门移动应用开发大作业的项目编号。说实话当时选这个题多少带点功利心——e621和e926这两个同源的图像社区一共用一套数据库API结构几乎一样域名却分两个入口天然适合做成一个“一套代码适配两个数据源”的移动客户端。再加上这类Booru平台本身就是图片密集型应用网络请求、列表缓存、图片懒加载、本地收藏、用户登录态管理几乎把移动端的所有基本功全串起来了。做完这个项目回头看它确实是一个性价比极高的大作业选题。这篇文章就把我整个开发过程、遇到的技术坑、以及最后怎么撑过验收的经验完整写出来。不管你是正在找大作业方向的学生还是想了解图像社区客户端怎么做的人应该都能从中拿到一些能直接抄作业的东西。1. e1547是什么一个把e621和e926装进手机里的客户端项目1.1 同一套内容两个不同入口先说清楚e621和e926到底是什么关系。它们不是两个独立的社区而是同一个内容数据库开放出来的两个前端入口。e621面向的是保留完整内容的用户而e926从服务器端就做了内容过滤只露出适合更广泛人群浏览的部分。这个设计对客户端开发来说是一个非常友好的起点。因为两个站点使用相同的API规范、相同的数据结构只是域名不同、可访问的内容范围不同。也就是说我只需要写一套网络层、一套解析逻辑、一套UI界面然后通过配置不同的baseUrl就能让同一个App拿到两个数据源的内容。在移动端开发里这种“同一套代码适配多端”的项目最能体现你对架构设计的理解。1.2 为什么值得做成移动应用这类图片社区在桌面浏览器里用起来体验其实还行但到了手机上就有几个很现实的问题首先是页面重图片多浏览器加载慢其次是翻页不够顺滑面对大量图片时桌面网页版的点击翻页模式远不如移动端的无限滚动来得爽快。除此之外手机端可以做的本地化操作——比如长按保存、离线收藏、浏览历史管理——都比网页端方便得多。所以这个移动应用的核心定位就出来了一个专门为e621/e926这类Booru平台打造的轻量客户端用户可以用它刷图、搜索、看大图、收藏和管理历史记录。对移动开发的学习来说它几乎覆盖了从网络层到UI层的整条链路。2. Booru类API的机制决定客户端怎么写2.1 不需要OAuth的登录方式很多同学一上来就默认所有API都是OAuth 2.0那套流程结果翻文档发现完全不是这回事。e621/e926的API走的是最传统的Session-Cookie模式你先拿用户名和密码请求登录接口服务端返回一个包含会话信息的Cookie后续请求把这个Cookie带上服务端就能识别你的身份。这个机制里有个容易被忽略的小细节——请求登录接口之前通常要先访问一次站点、把返回的CSRF token提取出来再把它作为表单参数一起提交登录请求。我第一次写的时候没注意直接裸POST用户名密码结果服务端一直返回403排查了半天才发现是CSRF校验没过。对大作业来说如果你不想把时间耗在登录态这种偏底层的逻辑上可以先做只读模式不登录也能通过公开API拉取帖子内容只是收藏和评分功能用不了。我建议的路线是先跑通免登录的浏览、搜索、看图再把登录加上去做收藏同步这样即使最后时间不够核心功能也已经完整了。2.2 tags查询是核心魔法这类Booru平台最大的特点就是万物皆标签。图片被上传后社区用户会给它打上大量的描述性标签包括角色、物种、场景、画师等维度。搜索的本质就是拼接tags参数。比如请求GET https://e926.net/posts.json?tagscaninerating:safelimit20page1这个请求的意思是查找标签包含canine、且内容分级为safe的帖子每页返回20条取第一页。返回的JSON数组里每条帖子包含id、file_url、preview_file_url、tags、score等关键字段客户端拿到这些数据直接就能渲染。更进阶的用法是屏蔽标签。比如用户不希望在结果里看到某个特定内容就在tags参数里加一个负号前缀GET https://e926.net/posts.json?tags-horrorlimit20page1把多个屏蔽条件用空格拼接就能组合出相当精细的过滤逻辑。这部分我会在第四节详细展开因为它是这个项目里最值得写的安全策略。2.3 速率限制是隐形的雷Booru类API基本都有访问频率限制而且限制得不宽松。以公开API为例未登录状态下的请求间隔通常要求控制在每秒1-2次以内如果短时间内狂刷接口IP会被临时封禁。这个规则并不写在显眼位置但踩一次就记住了。我的做法是做一个简单的请求队列——把每次请求放进队列保证任意两个请求之间至少有500毫秒的间隔再配合本地缓存同一个关键词分页数据在短时间内不重复请求。结果就是正常刷页面的时候几乎不会触发限流评分反而因为你主动做了节流加了分。3. 客户端结构怎么拆模块才不留死穴3.1 技术选型Flutter省力且好演示技术栈我选了Flutter。理由很实际首先一份代码同时跑Android和iOS答辩演示的时候不用纠结用什么系统的手机其次Flutter的GridView、ListView、缓存图片等生态组件非常成熟写这类图片流应用几乎就是拼装积木最后UI表现力够强滑动流畅度也够不会出现那种“能跑但是卡得没法看”的尴尬。状态管理我用的是Provider没有引入太重的东西。因为项目的状态量其实不多登录状态、搜索关键词、过滤标签集合、收藏列表。Provider做这种粒度刚好够用代码也好懂答辩时也容易讲清楚。3.2 网络层设计一个Client适配两个域名网络层是整个项目的核心我单独拆了一个ApiClient类。这个类对外暴露的接口是通用的比如fetchPosts、fetchPostDetail、login、favoritePost内部根据一个全局配置决定请求走的是e621还是e926域名。关键设计是一个域名的配置对象class SiteConfig { final String baseUrl; final String apiPath; final bool safeOnly; const SiteConfig({ required this.baseUrl, required this.apiPath, this.safeOnly true, }); }e621和e926各声明一个实例App启动时根据用户选择或者默认设置切换。这样做的好处是将来如果官方再开放一个新域名只需要加一个配置对象所有业务层代码一行都不用改。网络请求库用dio拦截器里统一做了三件事加User-Agent、加Cookie头、加超时时间。这三个看起来不起眼但每一个都对应后面的一个坑。3.3 本地存储浏览历史和收藏怎么落盘手机App和大网页的核心区别就是本地能力。我把本地存储分成了两层轻量级的键值对用shared_preferences存用户配置和登录Cookie结构化的收藏列表用sqflite存SQLite数据库。为什么收藏不用shared_preferences因为收藏是会持续增长的列表数据用数据库存不仅查询方便还能按时间排序、去重、以及后续加导入导出功能。浏览历史我用的是一个简单的表结构帖子ID、缩略图URL、大图URL、标签快照、浏览时间。存标签快照这个动作特别有用因为帖子内容可能会在服务端被修改或者下架但用户本地保存的历史记录仍然能看到当时的标签信息完整还原浏览场景。4. 内容过滤不只是调一个参数忽略这些会出大事4.1 先明白服务端过滤和客户端过滤的区别很多人的第一反应是既然e926在服务端已经过滤过内容了那客户端直接拉就行为什么还要再做过滤这个想法忽略了一个关键事实e926的过滤解决的是“内容发布时是否可见”的问题而客户端过滤解决的是“某个具体用户是否愿意看到”的问题。举个例子同样是安全内容有的用户可能不想看到特定标签这时候就必须在客户端做二次过滤。4.2 tags参数的组合过滤逻辑我在设置页里放了一个可编辑的“屏蔽标签列表”用户可以添加任意标签。每次搜索请求时把用户配置的屏蔽标签拼到tags参数里前面加负号String buildFilteredTags(String baseQuery) { final blockedTags preference.getBlockedTags(); if (blockedTags.isEmpty) return baseQuery; final blockedQuery blockedTags.map((t) -$t).join( ); return $baseQuery $blockedQuery; }这样一来服务端在返回结果时就已经把用户不想要的内容排除了流量也省了用户体验也好了。这个逻辑虽然简单但把“过滤”这件事从客户端推进到了服务端在架构上是一次质的提升。4.3 客户端兜底过滤防的就是缓存脏数据只做服务端过滤是不够的。原因很简单客户端可能有缓存缓存里可能存着用户还没设置屏蔽标签时拉下来的旧数据。用户设置新屏蔽标签后App从缓存读出来的数据可能包含已经不该出现的帖子。所以我在数据层加了一道兜底过滤——不管数据是从网络新拉来的还是从缓存读出来的在上屏之前都要过一遍当前的屏蔽标签列表。如果一条帖子的tags里包含任意屏蔽标签直接丢弃不进列表。ListPost filterPosts(ListPost posts) { final blockedTags preference.getBlockedTags().toSet(); return posts.where((post) { return !post.tags.any((tag) blockedTags.contains(tag)); }).toList(); }这道逻辑很直白但它在真实使用中的价值极大。因为你没办法保证服务端的返回永远是干净的也没办法保证中间代理不会拼接脏数据。做一层兜底是防御性编程思想最典型的体现。4.4 默认安全策略把默认值设为最安全的值最后说一下默认值的问题。这个App支持切换e621和e926两个数据源我从设计上就把默认数据源设为e926并且把内容分级过滤的默认值设为safe。用户如果要切换到e621必须手动确认一个弹窗同时App会强制把分级过滤提升到最高级别。这样的话即使手机被借给小孩玩或者用户粗心大意没做任何设置默认情况下看到的都是经过过滤的内容。这个设计在答辩时是一个绝对的加分项因为它体现的不只是“我能调API”而是“我能意识到这类平台在内容安全方面需要承担的责任”。对有真实用户的产品来说这种思考深度是必需的。5. 图片加载与缓存刷图App的体验瓶颈5.1 缓存层级问题别把原图塞进内存图片类应用最容易出的性能问题就是缓存层级不分。很多初学者喜欢把网络图片直接丢进内存缓存结果页面一多内存直接飙升然后就被系统杀掉。正确的做法是分层缓存内存里只放缩略图用LRU算法控制上限比如50MB原图只做磁盘缓存限制总容量比如500MB超过之后按照访问时间清理最旧的文件。这样至少把内存占用降了一个量级。图片库我选的是cached_network_image它自己实现了内存和磁盘双层缓存并且支持占位图、错误图。20张缩略图的列表页加载基本上不会出现卡顿滑动起来跟在桌面端浏览器里的体验差不多。5.2 瀑布流列表的懒加载策略这种图片社区的信息流最适合用两列GridView来实现每列宽度固定图片按比例显示缩略图接近正方形。懒加载的逻辑是滚动到底部之前预留出两屏的缓冲然后触发下一批数据的加载。if (scrollController.position.extentAfter 600) { loadMorePosts(); }在loadMorePosts里要先查缓存缓存没有才发网络请求网络请求回来之后再写缓存。写完缓存之后还要再跑一遍客户端兜底过滤然后才setState更新列表。这个顺序不能乱乱一步就会出现“刚刷出来的帖子已经不该显示了但还挂着”的bug。5.3 大图查看页的用户体验细节点击列表项进入大图查看页时不要直接加载原图而要先用缩略图撑住页面再异步替换成原图。这个“先模糊后清晰”的效果不仅看着舒服而且能避免用户反复点击后觉得“这个App反应好慢”。大图页还有一个实用小功能双指缩放。Flutter里用InteractiveViewer组件就能实现代码量不到20行但体验提升非常明显。答辩演示的时候评委通常会点开大图划几下这个交互细节能留下很好的第一印象。6. 大作业实操复盘值得记录的排查过程6.1 403问题User-Agent被服务端拒了第一次请求API的时候我用dio直接GET返回403而且响应体里看到一段提示代码。当时以为是Cookie或者IP出了问题排查了很久才发现问题出在User-Agent上。e621/e926的API要求客户端必须携带自定义的User-Agent里面要包含应用名称、版本号和联系方式裸请求会被服务端直接拒绝。解决办法是在dio拦截器里统一设置dio.options.headers[User-Agent] E1547Client/1.0 (contact: youremail.com);这个坑本身不难但能提醒你公共API的调试中响应头信息永远比猜测更有价值。遇到403别瞎试先看服务端给的具体错误信息。6.2 Cookie过期登录态失效的静默处理Session-Cookie模式最大的痛点就是Cookie会过期。e621的会话Cookie有效时间大概是一天到一周不等过期之后再调收藏接口服务端返回403或者401。如果客户端不做处理用户会看到“收藏失败”这种莫名其妙的结果。正确处理是请求返回401/403时先判断是不是登录接口本身报错如果不是就触发静默重登录——用本地保存的用户名密码重新调用登录接口、刷新Cookie、再重放刚才失败的请求。这个重放逻辑用dio的拦截器实现很方便在error回调里拦截状态码处理好之后拿到新的Cookie再重新发起一次请求。实现这个机制后用户基本感知不到登录过期的问题。6.3 限流被拒请求排队的必要性开发调试阶段有一回我连续翻了几十页搜索结果结果突然所有请求都开始返回429。这就是典型的触发限流了。好在服务端的限制时间不长等几分钟就恢复了但这也让我意识到不在客户端做节流是不行的。最后我写了一个简单的请求队列核心逻辑是所有请求进入队列后保证相邻两个请求的执行间隔不低于500毫秒。用dart的Stream或者简单的Timer都能实现。实测下来正常刷图、搜索、加载大图的节奏完全不受影响但API的封禁风险大幅下降。节流这个动作本身不应该只被认为是为他人考虑的设计它保证了应用自身的可用性。6.4 真机演示别抱着模拟器上答辩台最后这个坑跟代码无关但比任何一个代码问题都致命。Android模拟器连不上某些无线服务、图片加载速度更慢这都是小问题。真正的问题是模拟器的网络环境跟真机差距很大答辩现场一旦Wi-Fi信号差模拟器的请求超时概率远高于真机。所以答辩前一定要用真机做至少三次完整演示确保从启动App到刷出图片、打开搜索、登录、收藏全流程不卡壳。我还准备了一个热点作为备用网络防一手现场Wi-Fi出幺蛾子。写完这个项目之后我的一些体会从立项到答辩这个项目前后花了我三周时间。第一周搭骨架、跑通API第二周做列表、搜索和图片加载第三周集中处理过滤策略、缓存优化和收尾测试。回头来看这个选题最大的价值不只是让我学会了Flutter而是让我完整经历了一遍“面对真实API设计客户端”的整个过程——包括读文档、踩坑、限流、Cookie过期、数据过滤这些实战问题全都是教科书里不会写的东西。如果你想拿这个方向做自己的大作业我建议先把只读模式跑通再逐步加上登录、收藏、过滤这些进阶功能。对于打分来说功能完整是基本盘而你在过滤策略和缓存分层上做的思考才是真正让项目脱颖而出的地方。本文还有配套的精品资源点击获取 e1547开发实录：Flutter打造双数据源Booru客户端
简介这是一个基于Flutter/Dart开发的开源移动应用项目面向移动开发者与Flutter爱好者专门用于浏览e621与e926平台。它集成了帖子与图片池的搜索浏览、修图评论、图片下载上传、热门与收藏访问、标签关注、本地黑名单、DText文本解析、视频播放、自动更新检查以及多主题切换等二十余项功能完整覆盖了内容社区类App的常见业务闭环适合作为学习跨平台工程架构的参考样例。资源包共185个文件压缩后约29.59MB其中108个dart源文件构成主要业务逻辑与界面32个png和7个jpg提供图标与演示素材另有gradle、plist、storyboard、xcconfig等Android/iOS工程配置文件以及json、yaml、md等说明与依赖文件目录组织清晰能够帮助观察Flutter项目的模块划分与原生平台接入方式。目前已有3100人学习下载。通过剖析其中的帖子详情页、文本解析器、视频播放组件、设置面板与标签Wiki入口可以快速掌握Flutter下复杂列表交互、本地存储和网络请求的综合用法对开发或扩展此类移动应用有直接的参考价值。 “e1547”这个代号是我一门移动应用开发大作业的项目编号。说实话当时选这个题多少带点功利心——e621和e926这两个同源的图像社区一共用一套数据库API结构几乎一样域名却分两个入口天然适合做成一个“一套代码适配两个数据源”的移动客户端。再加上这类Booru平台本身就是图片密集型应用网络请求、列表缓存、图片懒加载、本地收藏、用户登录态管理几乎把移动端的所有基本功全串起来了。做完这个项目回头看它确实是一个性价比极高的大作业选题。这篇文章就把我整个开发过程、遇到的技术坑、以及最后怎么撑过验收的经验完整写出来。不管你是正在找大作业方向的学生还是想了解图像社区客户端怎么做的人应该都能从中拿到一些能直接抄作业的东西。1. e1547是什么一个把e621和e926装进手机里的客户端项目1.1 同一套内容两个不同入口先说清楚e621和e926到底是什么关系。它们不是两个独立的社区而是同一个内容数据库开放出来的两个前端入口。e621面向的是保留完整内容的用户而e926从服务器端就做了内容过滤只露出适合更广泛人群浏览的部分。这个设计对客户端开发来说是一个非常友好的起点。因为两个站点使用相同的API规范、相同的数据结构只是域名不同、可访问的内容范围不同。也就是说我只需要写一套网络层、一套解析逻辑、一套UI界面然后通过配置不同的baseUrl就能让同一个App拿到两个数据源的内容。在移动端开发里这种“同一套代码适配多端”的项目最能体现你对架构设计的理解。1.2 为什么值得做成移动应用这类图片社区在桌面浏览器里用起来体验其实还行但到了手机上就有几个很现实的问题首先是页面重图片多浏览器加载慢其次是翻页不够顺滑面对大量图片时桌面网页版的点击翻页模式远不如移动端的无限滚动来得爽快。除此之外手机端可以做的本地化操作——比如长按保存、离线收藏、浏览历史管理——都比网页端方便得多。所以这个移动应用的核心定位就出来了一个专门为e621/e926这类Booru平台打造的轻量客户端用户可以用它刷图、搜索、看大图、收藏和管理历史记录。对移动开发的学习来说它几乎覆盖了从网络层到UI层的整条链路。2. Booru类API的机制决定客户端怎么写2.1 不需要OAuth的登录方式很多同学一上来就默认所有API都是OAuth 2.0那套流程结果翻文档发现完全不是这回事。e621/e926的API走的是最传统的Session-Cookie模式你先拿用户名和密码请求登录接口服务端返回一个包含会话信息的Cookie后续请求把这个Cookie带上服务端就能识别你的身份。这个机制里有个容易被忽略的小细节——请求登录接口之前通常要先访问一次站点、把返回的CSRF token提取出来再把它作为表单参数一起提交登录请求。我第一次写的时候没注意直接裸POST用户名密码结果服务端一直返回403排查了半天才发现是CSRF校验没过。对大作业来说如果你不想把时间耗在登录态这种偏底层的逻辑上可以先做只读模式不登录也能通过公开API拉取帖子内容只是收藏和评分功能用不了。我建议的路线是先跑通免登录的浏览、搜索、看图再把登录加上去做收藏同步这样即使最后时间不够核心功能也已经完整了。2.2 tags查询是核心魔法这类Booru平台最大的特点就是万物皆标签。图片被上传后社区用户会给它打上大量的描述性标签包括角色、物种、场景、画师等维度。搜索的本质就是拼接tags参数。比如请求GET https://e926.net/posts.json?tagscaninerating:safelimit20page1这个请求的意思是查找标签包含canine、且内容分级为safe的帖子每页返回20条取第一页。返回的JSON数组里每条帖子包含id、file_url、preview_file_url、tags、score等关键字段客户端拿到这些数据直接就能渲染。更进阶的用法是屏蔽标签。比如用户不希望在结果里看到某个特定内容就在tags参数里加一个负号前缀GET https://e926.net/posts.json?tags-horrorlimit20page1把多个屏蔽条件用空格拼接就能组合出相当精细的过滤逻辑。这部分我会在第四节详细展开因为它是这个项目里最值得写的安全策略。2.3 速率限制是隐形的雷Booru类API基本都有访问频率限制而且限制得不宽松。以公开API为例未登录状态下的请求间隔通常要求控制在每秒1-2次以内如果短时间内狂刷接口IP会被临时封禁。这个规则并不写在显眼位置但踩一次就记住了。我的做法是做一个简单的请求队列——把每次请求放进队列保证任意两个请求之间至少有500毫秒的间隔再配合本地缓存同一个关键词分页数据在短时间内不重复请求。结果就是正常刷页面的时候几乎不会触发限流评分反而因为你主动做了节流加了分。3. 客户端结构怎么拆模块才不留死穴3.1 技术选型Flutter省力且好演示技术栈我选了Flutter。理由很实际首先一份代码同时跑Android和iOS答辩演示的时候不用纠结用什么系统的手机其次Flutter的GridView、ListView、缓存图片等生态组件非常成熟写这类图片流应用几乎就是拼装积木最后UI表现力够强滑动流畅度也够不会出现那种“能跑但是卡得没法看”的尴尬。状态管理我用的是Provider没有引入太重的东西。因为项目的状态量其实不多登录状态、搜索关键词、过滤标签集合、收藏列表。Provider做这种粒度刚好够用代码也好懂答辩时也容易讲清楚。3.2 网络层设计一个Client适配两个域名网络层是整个项目的核心我单独拆了一个ApiClient类。这个类对外暴露的接口是通用的比如fetchPosts、fetchPostDetail、login、favoritePost内部根据一个全局配置决定请求走的是e621还是e926域名。关键设计是一个域名的配置对象class SiteConfig { final String baseUrl; final String apiPath; final bool safeOnly; const SiteConfig({ required this.baseUrl, required this.apiPath, this.safeOnly true, }); }e621和e926各声明一个实例App启动时根据用户选择或者默认设置切换。这样做的好处是将来如果官方再开放一个新域名只需要加一个配置对象所有业务层代码一行都不用改。网络请求库用dio拦截器里统一做了三件事加User-Agent、加Cookie头、加超时时间。这三个看起来不起眼但每一个都对应后面的一个坑。3.3 本地存储浏览历史和收藏怎么落盘手机App和大网页的核心区别就是本地能力。我把本地存储分成了两层轻量级的键值对用shared_preferences存用户配置和登录Cookie结构化的收藏列表用sqflite存SQLite数据库。为什么收藏不用shared_preferences因为收藏是会持续增长的列表数据用数据库存不仅查询方便还能按时间排序、去重、以及后续加导入导出功能。浏览历史我用的是一个简单的表结构帖子ID、缩略图URL、大图URL、标签快照、浏览时间。存标签快照这个动作特别有用因为帖子内容可能会在服务端被修改或者下架但用户本地保存的历史记录仍然能看到当时的标签信息完整还原浏览场景。4. 内容过滤不只是调一个参数忽略这些会出大事4.1 先明白服务端过滤和客户端过滤的区别很多人的第一反应是既然e926在服务端已经过滤过内容了那客户端直接拉就行为什么还要再做过滤这个想法忽略了一个关键事实e926的过滤解决的是“内容发布时是否可见”的问题而客户端过滤解决的是“某个具体用户是否愿意看到”的问题。举个例子同样是安全内容有的用户可能不想看到特定标签这时候就必须在客户端做二次过滤。4.2 tags参数的组合过滤逻辑我在设置页里放了一个可编辑的“屏蔽标签列表”用户可以添加任意标签。每次搜索请求时把用户配置的屏蔽标签拼到tags参数里前面加负号String buildFilteredTags(String baseQuery) { final blockedTags preference.getBlockedTags(); if (blockedTags.isEmpty) return baseQuery; final blockedQuery blockedTags.map((t) -$t).join( ); return $baseQuery $blockedQuery; }这样一来服务端在返回结果时就已经把用户不想要的内容排除了流量也省了用户体验也好了。这个逻辑虽然简单但把“过滤”这件事从客户端推进到了服务端在架构上是一次质的提升。4.3 客户端兜底过滤防的就是缓存脏数据只做服务端过滤是不够的。原因很简单客户端可能有缓存缓存里可能存着用户还没设置屏蔽标签时拉下来的旧数据。用户设置新屏蔽标签后App从缓存读出来的数据可能包含已经不该出现的帖子。所以我在数据层加了一道兜底过滤——不管数据是从网络新拉来的还是从缓存读出来的在上屏之前都要过一遍当前的屏蔽标签列表。如果一条帖子的tags里包含任意屏蔽标签直接丢弃不进列表。ListPost filterPosts(ListPost posts) { final blockedTags preference.getBlockedTags().toSet(); return posts.where((post) { return !post.tags.any((tag) blockedTags.contains(tag)); }).toList(); }这道逻辑很直白但它在真实使用中的价值极大。因为你没办法保证服务端的返回永远是干净的也没办法保证中间代理不会拼接脏数据。做一层兜底是防御性编程思想最典型的体现。4.4 默认安全策略把默认值设为最安全的值最后说一下默认值的问题。这个App支持切换e621和e926两个数据源我从设计上就把默认数据源设为e926并且把内容分级过滤的默认值设为safe。用户如果要切换到e621必须手动确认一个弹窗同时App会强制把分级过滤提升到最高级别。这样的话即使手机被借给小孩玩或者用户粗心大意没做任何设置默认情况下看到的都是经过过滤的内容。这个设计在答辩时是一个绝对的加分项因为它体现的不只是“我能调API”而是“我能意识到这类平台在内容安全方面需要承担的责任”。对有真实用户的产品来说这种思考深度是必需的。5. 图片加载与缓存刷图App的体验瓶颈5.1 缓存层级问题别把原图塞进内存图片类应用最容易出的性能问题就是缓存层级不分。很多初学者喜欢把网络图片直接丢进内存缓存结果页面一多内存直接飙升然后就被系统杀掉。正确的做法是分层缓存内存里只放缩略图用LRU算法控制上限比如50MB原图只做磁盘缓存限制总容量比如500MB超过之后按照访问时间清理最旧的文件。这样至少把内存占用降了一个量级。图片库我选的是cached_network_image它自己实现了内存和磁盘双层缓存并且支持占位图、错误图。20张缩略图的列表页加载基本上不会出现卡顿滑动起来跟在桌面端浏览器里的体验差不多。5.2 瀑布流列表的懒加载策略这种图片社区的信息流最适合用两列GridView来实现每列宽度固定图片按比例显示缩略图接近正方形。懒加载的逻辑是滚动到底部之前预留出两屏的缓冲然后触发下一批数据的加载。if (scrollController.position.extentAfter 600) { loadMorePosts(); }在loadMorePosts里要先查缓存缓存没有才发网络请求网络请求回来之后再写缓存。写完缓存之后还要再跑一遍客户端兜底过滤然后才setState更新列表。这个顺序不能乱乱一步就会出现“刚刷出来的帖子已经不该显示了但还挂着”的bug。5.3 大图查看页的用户体验细节点击列表项进入大图查看页时不要直接加载原图而要先用缩略图撑住页面再异步替换成原图。这个“先模糊后清晰”的效果不仅看着舒服而且能避免用户反复点击后觉得“这个App反应好慢”。大图页还有一个实用小功能双指缩放。Flutter里用InteractiveViewer组件就能实现代码量不到20行但体验提升非常明显。答辩演示的时候评委通常会点开大图划几下这个交互细节能留下很好的第一印象。6. 大作业实操复盘值得记录的排查过程6.1 403问题User-Agent被服务端拒了第一次请求API的时候我用dio直接GET返回403而且响应体里看到一段提示代码。当时以为是Cookie或者IP出了问题排查了很久才发现问题出在User-Agent上。e621/e926的API要求客户端必须携带自定义的User-Agent里面要包含应用名称、版本号和联系方式裸请求会被服务端直接拒绝。解决办法是在dio拦截器里统一设置dio.options.headers[User-Agent] E1547Client/1.0 (contact: youremail.com);这个坑本身不难但能提醒你公共API的调试中响应头信息永远比猜测更有价值。遇到403别瞎试先看服务端给的具体错误信息。6.2 Cookie过期登录态失效的静默处理Session-Cookie模式最大的痛点就是Cookie会过期。e621的会话Cookie有效时间大概是一天到一周不等过期之后再调收藏接口服务端返回403或者401。如果客户端不做处理用户会看到“收藏失败”这种莫名其妙的结果。正确处理是请求返回401/403时先判断是不是登录接口本身报错如果不是就触发静默重登录——用本地保存的用户名密码重新调用登录接口、刷新Cookie、再重放刚才失败的请求。这个重放逻辑用dio的拦截器实现很方便在error回调里拦截状态码处理好之后拿到新的Cookie再重新发起一次请求。实现这个机制后用户基本感知不到登录过期的问题。6.3 限流被拒请求排队的必要性开发调试阶段有一回我连续翻了几十页搜索结果结果突然所有请求都开始返回429。这就是典型的触发限流了。好在服务端的限制时间不长等几分钟就恢复了但这也让我意识到不在客户端做节流是不行的。最后我写了一个简单的请求队列核心逻辑是所有请求进入队列后保证相邻两个请求的执行间隔不低于500毫秒。用dart的Stream或者简单的Timer都能实现。实测下来正常刷图、搜索、加载大图的节奏完全不受影响但API的封禁风险大幅下降。节流这个动作本身不应该只被认为是为他人考虑的设计它保证了应用自身的可用性。6.4 真机演示别抱着模拟器上答辩台最后这个坑跟代码无关但比任何一个代码问题都致命。Android模拟器连不上某些无线服务、图片加载速度更慢这都是小问题。真正的问题是模拟器的网络环境跟真机差距很大答辩现场一旦Wi-Fi信号差模拟器的请求超时概率远高于真机。所以答辩前一定要用真机做至少三次完整演示确保从启动App到刷出图片、打开搜索、登录、收藏全流程不卡壳。我还准备了一个热点作为备用网络防一手现场Wi-Fi出幺蛾子。写完这个项目之后我的一些体会从立项到答辩这个项目前后花了我三周时间。第一周搭骨架、跑通API第二周做列表、搜索和图片加载第三周集中处理过滤策略、缓存优化和收尾测试。回头来看这个选题最大的价值不只是让我学会了Flutter而是让我完整经历了一遍“面对真实API设计客户端”的整个过程——包括读文档、踩坑、限流、Cookie过期、数据过滤这些实战问题全都是教科书里不会写的东西。如果你想拿这个方向做自己的大作业我建议先把只读模式跑通再逐步加上登录、收藏、过滤这些进阶功能。对于打分来说功能完整是基本盘而你在过滤策略和缓存分层上做的思考才是真正让项目脱颖而出的地方。本文还有配套的精品资源点击获取