java web社交媒体应用的核心是控制复杂度，需实现注册、登录、发帖、看动态、互相关注五项基本功能；用户模块必须用spring security而非手写登录，密码须用bcrypt加密，动态流应采用redis推模式缓存，关注表需建复合唯一索引并禁用级联删除。
Java Web 社交媒体应用不是靠堆功能做出来的，而是靠分清边界、控制复杂度撑起来的。一个“基本”版本的核心不在于有多少酷炫交互，而在于用户能注册、登录、发帖、看到别人动态、互相关注——这五件事跑通了，骨架才算立住。
用户模块必须用 Spring Security 而不是手写登录
很多人从 HttpServletRequest.getParameter("username") 开始写登录，结果密码明文传输、Session 管理混乱、CSRF 漏洞频出。Spring Security 不是“可选框架”，它是防止你第一天上线就被扫号的底线。
- 必须配置
WebSecurityConfigurerAdapter（或基于SecurityFilterChain的新方式），禁用默认表单，启用基于 JWT 或 Session 的认证流程 - 密码必须用
BCryptPasswordEncoder加密存储，绝不能用MD5或SHA-256原生调用 -
UserDetailsService实现类里查库逻辑要加@Transactional(readOnly = true)，避免脏读 - 登录接口返回的 JSON 至少包含
token（JWT 场景）或sessionId（Session 场景），前端必须带在后续每个请求头里
动态流（Feed）不能实时查数据库，得用简单缓存策略
每次刷首页都执行 SELECT * FROM post WHERE user_id IN (SELECT followee_id FROM follow WHERE follower_id = ?) ORDER BY created_at DESC LIMIT 20，三个人同时刷，数据库连接就卡住。这不是性能问题，是设计误判。
- 启动时用
@PostConstruct加载热门用户最近 50 条动态到ConcurrentHashMap<string list>></string>，作为兜底缓存 - 用户发帖后，异步触发更新：往该用户所有粉丝的 Redis Sorted Set（如
feed:1001）里插入ZADD feed:1001 timestamp post_id - 首页拉取时只查 Redis：
ZREVRANGE feed:1001 0 19 WITHSCORES，再批量查 DB 补全内容 - 别一上来就搞推拉混合模式——先纯推模式，等日活过 500 再考虑冷用户降级为拉
关注关系建表必须加复合唯一索引，且禁止级联删除
follow 表看着简单，但没约束就会出现重复关注、删用户连带清空所有关注记录、查询变慢等问题。
立即学习“Java免费学习笔记（深入）”；
- 表结构至少含
follower_id、followee_id、created_at，主键设为联合主键或加唯一索引：ALTER TABLE follow ADD UNIQUE INDEX uk_follower_followee (follower_id, followee_id) -
ON DELETE CASCADE绝对禁用——删一个用户不该自动解绑几百人的关注关系，应由业务层显式调用解绑逻辑 - 查“我关注了谁”和“谁关注了我”必须走两个不同 SQL，别试图用
UNION合并，字段语义不同，分页逻辑也不同 - 关注数/粉丝数这类统计字段不要实时计算，用
UPDATE follow_counter SET following_count = following_count + 1 WHERE user_id = ?在关注动作中增减
真正卡住进度的往往不是“怎么实现点赞”，而是“发帖后要不要立刻通知所有粉丝”。这种问题没有标准答案，但有明确判断依据：你的数据库扛不扛得住、Redis 集群有没有配好、团队有没有人懂消息队列。先让数据可读可写，再谈实时性。
