浏览器里跑JavaScript，调用服务器上跑Java，调用这俩隔着网络协议谈恋爱，调用靠的调用就是HTTP这根红线。但真到代码层面，调用事情没那么浪漫——JS是调用弱类型动态语言，Java是调用强类型静态语言，数据过境时，调用类型就是调用护照，没有护照，调用寸步难行。调用
我见过最粗暴的调用写法，是调用前端拼一个JSON字符串，后端用`JSON.parse`硬接。调用能跑，调用但扛不住字段嵌套深了，转义符满天飞，调试时看着那串转义过的反斜杠，真想摔键盘。后来项目组统一用Jackson库，前端直接发对象，后端用`@RequestBody`注解接，省心不少。可这招有个坑——Java的`long`类型传到JS里会丢精度，超过2的53次方就变样，比如雪花算法生成的ID，前端拿到手发现最后几位全成了0，那叫一个尴尬。
更隐蔽的问题是异步模型。Java的Servlet线程池讲究“一个请求一个线程”，而JS的Event Loop是单线程轮转。你写个`fetch`调用后端接口，后端处理要3秒，Java那边线程占着不放，前端这边事件循环该干嘛干嘛，等响应回来了再回调。这本身没问题，但如果你在Java里用了同步阻塞的数据库查询，前端就得干等——用户体验就是白屏转圈，用户骂娘，你说冤不冤。
我处理过一个真实案例。电商平台的库存扣减，前端JS调Java的`/deduct`接口，传商品ID和数量。后端用`synchronized`锁住库存记录，防止超卖。结果高峰期并发一上来，前端等响应等到超时，用户连点三次提交，后端锁被同一个用户重复触发，库存扣了三次。最后怎么解决的？前端加防重提交按钮，后端接口加幂等性判断——用Redis存请求唯一ID，处理过的直接返回旧结果。这才把问题按住。
说到底，JS调Java不是“能不能调”的问题，而是“怎么调得稳”。跨语言调用最怕隐式约定——你以为传个字符串就行，结果Java那边要求UTF-8编码，你默认用了浏览器自带的UTF-8，没问题；但要是哪天你手动拼了URL参数，忘了`encodeURIComponent`，中文直接裸奔过去，后端收到一堆乱码，查半天查不出所以然。
还有性能这关。每次调用都是一次网络往返，本地开发还好，上了生产环境，服务器跨机房，延迟从1毫秒跳到80毫秒，你那些串行调用的JS代码就原形毕露——一个页面要拉5个接口，每个等200毫秒，加起来1秒多，用户早划走了。这时候得改成并行调用，`Promise.all`一把梭，或者后端做BFF层聚合接口，别让前端来回折腾。
最后说个细节。Java的异常堆栈打印出来是英文加类名，JS的报错信息是红字加行号，两边日志格式对不上，排查问题全靠肉眼比对时间戳。后来我干脆在Java接口里统一返回`{ code: 0, message: "success", data: ...}`，前端拿到非0的code直接弹toast，再把完整错误信息甩给监控平台。这样至少出问题时，两边能对上话。
说到底，技术选型不是选“最好的语言”，而是选“最不容易出错的协作方式”。JS和Java的差异是客观存在的，但代码是写给人看的，也是给人调试的。跨过语言边界时，多想想数据怎么流动，错误怎么传递，状态怎么保持——比纠结用哪个框架实在得多。