金融科技后端面试经常问 Java、数据库、缓存、项目经历，但它和普通互联网后端有一个明显区别：面试官更在意一致性、审计、权限和风险边界。你可以不会把所有金融业务都说得很深，但必须知道哪些地方不能含糊。
如果回答只围绕 Spring、Redis、MySQL 的用法，很容易像通用八股。更好的方式，是把技术点放到金融业务动作里：转账、扣款、额度、账单、审批、对账、风控。技术不是孤立展示，而是为“钱和状态不能错”服务。
事务题要落到业务动作
金融场景里，事务不是“加一个注解”。面试官可能会问：一个扣款流程里哪些步骤必须放在同一个事务里？调用外部支付渠道失败怎么办？用户重复提交会不会重复扣款？
一个稳的回答是：本地账户状态、流水记录、关键状态变更要保持一致；外部系统调用不能简单依赖本地事务回滚，因为外部动作已经发生或状态未知；对于不确定状态，要通过查询、对账或补偿任务收敛。
如果你能把“未知状态”讲清楚，会比只说 ACID 更有含金量。支付渠道超时并不代表失败，它可能已经扣款，也可能没有处理。此时系统应该进入处理中状态，通过主动查询或回调确认最终结果，而不是立刻把订单标成失败。
幂等要有业务唯一键
金融接口很容易遇到重复请求：用户重复点击、网关重试、消息重复投递、第三方回调多次到达。幂等不是一句“加锁”，而是要有业务唯一键。支付流水号、订单号加操作类型、请求流水号，都可以作为幂等判断依据。
几个高频场景可以这样讲：用户重复提交时，用请求流水号和状态机挡住重复扣款；第三方重复回调时，用回调流水唯一约束避免状态反复修改；消息重复消费时，先查消费记录，再执行业务变更；补偿任务重跑时，要记录补偿批次和审计结果，避免二次修正错误。
这里的重点是，幂等设计要贴着业务动作。不同操作不能混用一个模糊 key，否则会把本该执行的新动作误判成重复请求。
审计和对账要主动提
金融科技项目里，很多问题不是当场报错，而是事后发现数据不一致。面试里如果能主动提审计和对账，会显得更贴近业务。流水记录、操作人、时间、前后状态、外部请求号、返回码，这些都是排查和追责的基础。
对账不是只有财务系统才需要。只要涉及多个系统状态同步，就应该考虑定期校验：本地订单状态和渠道状态是否一致，账务流水和业务单据是否一致，消息发送和消费是否闭环。
正确性优先，但不是不要性能
金融科技后端不是不能谈性能，但不要把性能放在正确性前面。更专业的表达是：我会先保证核心状态正确、可审计、可补偿，再考虑缓存、异步和并发优化。缓存可以提升读性能，但余额、额度、扣款结果这类字段不能随便用旧值兜底。
如果被追问“性能和一致性冲突怎么办”，不要简单说牺牲性能。更好的回答是分层：核心账务链路优先正确性，读多写少的展示链路可以用缓存和异步刷新；强一致字段要回源或使用权威服务，展示型字段可以接受短暂延迟。这样的取舍更接近真实金融科技系统。