Spring框架中Java if-else执行异常及文章点赞功能逻辑问题排查

云原生阿岚

2026-5-19

我来分别解答你的两个问题：

问题1：Spring框架中Java的if-else语句无法正确执行？

这种情况很少是if-else语法本身的问题，大多是Spring环境下的特殊场景导致逻辑不符合预期，常见原因有这些：

代理机制的坑：如果你的代码依赖Spring代理（比如用了@Transactional、AOP切面等），同一个类内的方法调用不会触发代理逻辑。举个例子：你在A.method1()里调用了同一个类的A.method2()，而method2上有事务注解，这时候method2的事务不会生效，可能导致你在method2里的if-else基于错误的事务状态执行，看起来像是if-else“失效”了。
对象相等性判断错误：很多人会用==来比较对象（比如String、自定义User类），但==比较的是内存地址，不是内容。比如判断当前用户是否是目标用户时，用if (user == currentUser)，如果两个是不同实例但ID相同，判断就会出错，应该用Objects.equals(user.getId(), currentUser.getId())来比较唯一标识，避免空指针的同时保证判断准确。
事务/缓存导致的状态不一致：如果你的if-else依赖数据库数据，但事务还没提交，或者缓存没更新，就会基于旧数据判断。比如你在事务里修改了某个字段，但还没commit，这时候同线程的if-else可能看到的还是旧值，导致逻辑走偏。
并发下的变量可见性问题：如果多线程操作共享变量，没有用volatile修饰，或者没有加锁，线程可能看不到其他线程修改后的最新值，导致if-else的条件判断基于过期数据。
逻辑分支的隐性退出：比如if分支里有return、throw异常的代码，直接提前退出了方法，导致else分支根本没机会执行。比如你写了if (condition) { return result; } else { ... }，但你误以为condition为true时else还会执行，其实不是。

问题2：文章点赞功能重复添加用户且点赞数异常？

根据你描述的“遍历数组校验用户是否存在但仍重复添加”，大概率是校验逻辑或者并发/持久化的问题，常见的几个坑：

校验时的对象匹配错误：这是最常见的原因！你遍历点赞数组时，可能用了==比较用户对象，而不是比较用户的唯一标识（比如ID）。举个错误示例：

boolean hasLiked = false;
for (User user : article.getLikedUsers()) {
    // 这里如果user和currentUser是不同实例，即使ID相同也会返回false
    if (user == currentUser) {
        hasLiked = true;
        break;
    }
}

正确的做法是比较用户的唯一标识，比如ID：

boolean hasLiked = false;
Long currentUserId = currentUser.getId();
for (User user : article.getLikedUsers()) {
    if (Objects.equals(user.getId(), currentUserId)) {
        hasLiked = true;
        break;
    }
}

并发修改导致的校验-修改窗口：当多个用户同时点赞同一篇文章时，可能出现“你刚校验完用户不在列表里，另一个线程已经把用户加进去了”的情况，导致重复添加。解决办法包括：
- 用线程安全的集合，比如CopyOnWriteArrayList来存储点赞用户；
- 在数据库层面加联合唯一约束（文章ID+用户ID），从根源上阻止重复数据；
- 给文章对象加锁，比如用synchronized(article)包裹校验和修改的逻辑。
持久化时的覆盖问题：如果你先查询文章到内存，修改点赞列表和点赞数，再保存到数据库，中间如果有其他请求修改了数据库的文章记录，你的保存会覆盖掉之前的修改，导致看起来重复添加。这种情况可以用乐观锁解决：给文章表加一个version字段，更新时带上WHERE id = ? AND version = ?的条件，确保只有基于最新版本的修改才会生效。
分支逻辑写反：仔细检查你的代码，是不是校验到用户存在后，反而执行了添加用户、点赞数+1的逻辑，而不是移除用户、点赞数-1？比如把if (hasLiked)和else里的代码写反了，这种低级错误很容易犯，一定要核对一遍。

内容的提问来源于stack exchange，提问作者Dan Durnev