CASE STUDY
2026.02.27–03.07 · 模块开发与复审 · 团队项目 · 模块协作Feb 27–Mar 7, 2026 · module development and review · Team project · module collaboration
EventAccount：我负责发现页，为什么审查追到了报名事务？
EventAccount 是团队活动平台项目。我的职责包括个人中心、发现模块和落地页的产品与交互决策，相关代码由 AI 编程工具完成。认证、活动管理、通知等还有其他团队模块，本文不将整个平台计为个人独立成果。
团队约定每位模块负责人完成相应前后端与本地联调，再提交合并。2026 年 2 月底至 3 月初，我在这个边界里推进功能；发现页复审则暴露了跨模块的问题。
页面隐藏草稿，还不等于接口只返回公开活动
3 月 7 日的复审记录显示，前后端可以构建，已有定向测试也通过，但公开接口仍存在高优先级问题：允许客户端传入非公开状态，详情缺少可见性限制，列表还选择了不应公开的手机号字段。
这不是页面再加一个筛选器就能解决的事。改进需要进入后端查询和返回字段：由服务端强制公开边界，缩小返回数据，再让前端消费结果。文档与后续加固提交记录了这些调整，不能把原先测试通过当成安全已经完整覆盖。
同一个搜索框，也会有时间顺序问题
连续搜索或快速切换城市时，较早发出的慢请求可能最后返回，覆盖新的筛选结果。此时 URL、页码和列表各自看起来合理，放在一起却不是同一次查询。
主搜索已有防抖与取消机制，复审仍发现部分子页保护不足。检查因此需要按页面和请求路径展开，不能因为共用一个外观就认为内部行为一致。URL 同步也要覆盖后退、刷新和城市切换。
发现页使用的接口，连接着其他人的业务状态
发现模块展示活动、票量和报名状态。继续检查时，问题追到了取消报名与候补递补：释放一个名额后，如果两个操作同时看见空位，就可能出现状态和票量不一致。
后续架构说明与加固提交记录了将相关修改放进同一事务、在必要处加锁，并复核票种容量的处理。我的参与在模块边界与这次联调审查内，不代表所有报名能力都由我独立设计和验收。
团队协作在这里需要交接的内容包括：哪个接口给发现页用、谁负责权限条件、状态变化涉及哪些表，以及哪些回归还没覆盖。只交接页面地址与功能列表，会把这些依赖留给下一个人猜。
合并前留下可追踪的差异
当前材料保留了职责表、架构文档、复审报告与加固提交，也列出部分空实现和待对齐字段。本文未重跑团队项目或并发压测，不能给出当前生产安全结论；项目文档的展示范围仍是本地运行。
EventAccount: how reviewing discovery reached registration transactions
EventAccount is a team activity-platform project. I owned product and interaction decisions for account settings, discovery, and landing pages, with implementation by AI coding tools. Other team modules cover authentication, event management, notifications, and more. I do not claim the whole platform as independent work.
The team assigned front-to-back module ownership and local integration before merge. My work in late February and early March 2026 encountered dependencies beyond the page boundary.
Public pages need a server-side data boundary
The March 7 review recorded successful builds and targeted tests alongside serious findings: public queries could accept non-public statuses, details lacked visibility restrictions, and a list selected a phone field that should not be public.
A frontend filter could not fix those conditions. Changes needed to constrain backend queries and returned fields. Later hardening and architecture records describe those adjustments; earlier passing tests did not establish complete safety coverage.
Search results also have an ordering problem
A slow earlier request can overwrite a later city or search selection. The URL, pagination, and results may then describe different queries.
The main search had debounce and cancellation, but review found gaps in subpages. Similar-looking controls still required path-specific checks, including back navigation, refresh, and city changes.
Discovery depends on registration state
Discovery displays activity and ticket information supplied by other modules. Review reached cancellation and waitlist promotion: concurrent operations could observe the same free place and leave ticket counts inconsistent with approval state.
Later documentation and hardening commits record transactional updates, locking, and ticket-capacity checks. My contribution concerns this integration and review scope; it does not establish sole ownership of registration design or complete concurrency validation.
The handoff therefore needed API ownership, authorization conditions, affected tables, and uncovered regressions. Page addresses and feature lists could not convey those dependencies.
Retain what the merge did and did not establish
The records include responsibility tables, architecture, review findings, and fixes, alongside remaining empty implementations and field mismatches. I did not rerun the team project or load tests for this article, and it makes no current production-safety claim.
Sources include the fixed-version responsibilities, the discovery review, and later architecture records. A future handoff should carry public-interface negative cases and cross-module state checks with it.