请分享一个你在交通银行前端项目中遇到的复杂问题（如高并发下的页面卡顿、数据一致性错误），你是如何分析和解决的？

1) 【一句话结论】

在高并发批量导入交易数据时，因网络波动导致部分API请求超时，引发数据不一致问题。通过引入请求重试机制与数据库事务控制，确保数据最终一致且页面响应正常，优化后数据提交成功率从85%提升至98%。

2) 【原理/概念讲解】

数据一致性是分布式系统核心问题，高并发下若请求失败未处理，会导致数据不一致。比如批量导入时，若某个请求因网络中断失败，后续操作可能基于未提交的数据，导致错误。类比：银行转账，若网络中断未重试，可能导致一方账户余额错误，需要重试确保最终一致。关键点：事务（ACID）保证数据完整性，重试机制处理临时网络问题。

3) 【对比与适用场景】

方式	定义	特性	使用场景	注意点
同步请求	请求发送后阻塞，等待响应	代码执行顺序固定，资源加载阻塞DOM	简单场景，少量请求	高并发下易卡顿，失败后需手动重试
异步请求（Promise）	请求发送后不阻塞，后续代码继续执行	非阻塞，可处理多个请求	高并发、需要快速响应的场景	需管理请求队列，避免内存泄漏
事务控制（数据库）	将多个操作视为一个单元，要么全部成功要么全部失败	保证数据完整性（ACID）	数据库操作，如批量插入	需考虑隔离级别，避免并发问题
重试机制	请求失败后自动重试	处理临时网络问题	高并发下易失败的请求	需设置重试次数，避免无限循环

4) 【示例】

伪代码示例（处理批量导入请求，结合重试与事务）：

function submitBatchData(dataList, callback) {
    const maxRetries = 3;
    let retryCount = 0;
    const queue = [];
    const maxConcurrent = 2;

    function processQueue() {
        while (queue.length > 0 && retryCount < maxRetries) {
            const { data, callback } = queue.shift();
            const retry = retryCount++;
            fetch('/api/import', {
                method: 'POST',
                body: JSON.stringify(data),
                headers: { 'Content-Type': 'application/json' }
            })
            .then(res => {
                if (!res.ok) throw new Error('API error');
                return res.json();
            })
            .then(result => {
                callback(null, result);
            })
            .catch(err => {
                if (retry < maxRetries) {
                    queue.push({ data, callback });
                } else {
                    callback(err);
                }
            })
            .finally(() => processQueue());
        }
    }

    dataList.forEach(data => {
        queue.push({ data, callback: (err, result) => {
            if (err) console.error('提交失败:', err);
            else console.log('提交成功:', result);
        }});
    });
    processQueue();
}

const data = [{id:1, amount:100}, {id:2, amount:200}];
submitBatchData(data, (err, results) => {
    if (err) console.error('批量提交失败');
    else console.log('批量提交成功', results);
});

5) 【面试口播版答案】

“之前在交通银行的一个批量交易导入项目中，遇到了高并发下的数据不一致问题。具体场景是，用户批量导入1000条交易数据时，部分请求因网络波动超时，导致数据未正确提交，页面显示部分导入成功但实际数据库有缺失。分析过程：首先用浏览器开发者工具的Network面板，发现大量请求状态为'network error'，检查API日志发现超时次数高；其次，代码中API请求是同步串行处理，并发数低但响应慢。解决方法：引入请求重试机制，设置最大重试3次，同时结合数据库事务，将批量操作封装为事务，确保要么全部成功要么回滚。优化后，数据提交成功率从85%提升至98%，页面响应时间从3秒缩短到1.2秒。”

6) 【追问清单】

• 问：重试机制中，如何避免无限重试？比如网络永久故障。
  答：设置最大重试次数（如3次），超过后记录错误并提示用户手动重试。
• 问：事务控制是否影响并发性能？比如隔离级别？
  答：使用读已提交（Read Committed）隔离级别，减少锁竞争，同时事务提交时批量处理，提升性能。
• 问：缓存策略如何配合？比如导入数据是否需要缓存？
  答：对静态导入模板使用HTTP缓存（如Cache-Control: max-age=3600），减少重复请求，但动态数据不缓存，避免数据不一致。

7) 【常见坑/雷区】

• 坑1：只说重试，没提事务，导致数据不一致（如部分成功部分失败）。
• 坑2：忽略重试次数，导致无限循环消耗资源。
• 坑3：事务隔离级别设置不当，导致并发下数据错误（如脏读）。
• 坑4：缓存策略错误，动态数据缓存导致数据不一致。
• 坑5：未考虑网络波动后的数据回滚，导致数据库异常。