工业现场Web NFC操作：不惧网络波动，前端如何实现数据本地缓存与断网续传？

2025/8/7 15:43:32 140 0 0 0

在工业自动化和物联网（IoT）的浪潮下，Web NFC技术正逐渐渗透到各种生产场景，例如设备巡检、物料追溯、工具管理等。想象一下，当你的工人手持一台支持Web NFC的移动设备，频繁地扫描NFC标签，将数据写入PLC（可编程逻辑控制器）来控制生产流程。然而，工业现场的网络环境往往复杂多变，信号差、间歇性中断是家常便饭。一旦网络不稳定，PLC指令写入失败，轻则效率低下，重则生产事故，这可不是闹着玩的。那么，作为一名身处一线的开发者，我们该如何在前端应用层面构建一个坚不可摧的“堡垒”，确保PLC指令永不丢失呢？

Web NFC的特性与工业场景的挑战

Web NFC允许Web应用通过NFC硬件读写NFC标签。它最大的优势在于无需安装原生应用，通过浏览器就能完成操作，极大地降低了部署和维护成本。然而，这项技术也有其“规矩”：必须在HTTPS环境下运行，且操作NFC需要用户手势触发。在工业现场，除了网络不稳定，还有以下挑战：

高频操作：工人可能需要连续扫描数百个标签，每次扫描都伴随着一次数据写入请求。
数据完整性：对PLC的指令写入是核心业务逻辑，任何一条指令的丢失都可能导致严重后果。
用户体验：网络延迟或中断不应阻塞前端操作，工人需要流畅的交互体验。

面对这些挑战，前端离线数据缓存与断网续传（Offline First）策略成为了必选项。

核心策略：IndexedDB + Service Worker + 幂等性

要解决上述问题，我们需要一个多管齐下的方案：

本地持久化存储：IndexedDB
网络状态感知与后台同步：Service Worker
操作可靠性：数据幂等性与重试机制

1. 选择合适的本地存储：为什么是IndexedDB？

localStorage、sessionStorage固然简单，但它们都有存储容量小（通常5MB）、只能存储字符串、同步操作阻塞主线程等缺点。对于需要存储大量结构化数据（如待写入PLC的指令队列）并进行异步非阻塞操作的工业场景，IndexedDB无疑是最佳选择。

IndexedDB是一个基于JavaScript的事务型数据库，运行在浏览器内部。它的优势在于：

容量大：通常可达数百MB甚至GB级别，足以应对大量离线数据。
异步操作：所有操作都是异步的，不会阻塞主线程，确保用户界面流畅。
结构化存储：可以存储JavaScript对象，方便数据存取。
事务支持：保证数据操作的原子性和一致性。

实现思路：

每次Web NFC扫描成功并获取到PLC写入指令后，无论当前网络状况如何，都立即将该指令以及必要的操作元数据（如时间戳、操作员ID、设备ID、重试次数等）存储到IndexedDB的一个“待发送队列”中。例如，我们可以设计一个名为pendingPlcCommands的Object Store，每个记录包含commandId, commandData, timestamp, status (pending, sent, failed)等字段。

// 伪代码示例：将NFC扫描数据存入IndexedDB
async function saveNfcCommandToIndexedDB(commandData) {
    const db = await openIndexedDB(); // 自定义函数，打开/创建IndexedDB数据库
    const transaction = db.transaction('pendingPlcCommands', 'readwrite');
    const store = transaction.objectStore('pendingPlcCommands');

    const command = {
        id: Date.now().toString(), // 简单的唯一ID
        data: commandData,         // 实际的PLC指令数据
        timestamp: new Date().toISOString(),
        status: 'pending',         // 初始状态为待发送
        retries: 0                 // 重试次数
    };

    return new Promise((resolve, reject) => {
        const request = store.add(command);
        request.onsuccess = () => {
            console.log('指令已成功存入本地队列:', command.id);
            resolve(command.id);
        };
        request.onerror = (event) => {
            console.error('指令存入IndexedDB失败:', event.target.errorCode);
            reject(event.target.error);
        };
    });
}

// Web NFC读取成功后调用
navigator.nfc.scan().then(async ({ message }) => {
    // ... 解析message获取PLC指令数据
    const plcCommand = parseNfcData(message);
    await saveNfcCommandToIndexedDB(plcCommand);
    // 无论网络如何，先给用户一个成功的反馈
    showToast('NFC数据已成功记录，等待同步...');
}).catch(error => {
    console.error('NFC扫描失败:', error);
    showToast('NFC扫描出错，请重试');
});

2. 利用Service Worker实现断网续传

Service Worker是浏览器和网络之间的可编程代理，能够拦截网络请求、缓存资源、并在后台运行，即使浏览器页面关闭也能执行任务。它是实现离线同步和断网续传的关键。

实现思路：

注册Service Worker：在应用启动时注册Service Worker。
网络状态监听：Service Worker可以监听online和offline事件，或者通过拦截失败的网络请求来判断网络状况。
Background Sync API (推荐)：这是Service Worker的一个扩展，允许在网络恢复时自动同步数据。当网络连接不可用时，你可以注册一个sync事件。一旦网络恢复，Service Worker就会被唤醒来处理这个事件。
请求拦截与重定向：虽然不是本次主要同步方式，但Service Worker也可以拦截发送到PLC的API请求。当网络离线时，Service Worker可以阻止请求发出，并在网络恢复时从IndexedDB中读取队列进行发送。

// service-worker.js 伪代码
self.addEventListener('sync', (event) => {
    if (event.tag === 'sync-plc-commands') {
        event.waitUntil(syncPlcCommands());
    }
});

async function syncPlcCommands() {
    const db = await openIndexedDB();
    const transaction = db.transaction('pendingPlcCommands', 'readwrite');
    const store = transaction.objectStore('pendingPlcCommands');

    const pendingCommands = await new Promise((resolve, reject) => {
        const request = store.getAll();
        request.onsuccess = () => resolve(request.result);
        request.onerror = (event) => reject(event.target.error);
    });

    for (const command of pendingCommands) {
        if (command.status === 'pending' || (command.status === 'failed' && command.retries < MAX_RETRIES)) {
            try {
                console.log(`尝试发送PLC指令: ${command.id}`);
                // 假设有一个API接口来发送指令到后端，后端再写入PLC
                const response = await fetch('/api/write-plc', {
                    method: 'POST',
                    headers: { 'Content-Type': 'application/json' },
                    body: JSON.stringify(command.data)
                });

                if (response.ok) {
                    await updateCommandStatus(db, command.id, 'sent');
                    console.log(`指令 ${command.id} 发送成功并更新状态。`);
                } else {
                    // 服务器返回错误，可能需要增加重试次数或标记为永久失败
                    throw new Error(`Server responded with ${response.status}`);
                }
            } catch (error) {
                console.error(`发送指令 ${command.id} 失败:`, error);
                await updateCommandStatus(db, command.id, 'failed', command.retries + 1);
            }
        }
    }
    console.log('所有待同步PLC指令处理完毕。');
}

// 辅助函数：更新IndexedDB中指令的状态和重试次数
async function updateCommandStatus(db, commandId, newStatus, newRetries = null) {
    const transaction = db.transaction('pendingPlcCommands', 'readwrite');
    const store = transaction.objectStore('pendingPlcCommands');
    const command = await store.get(commandId);
    if (command) {
        command.status = newStatus;
        if (newRetries !== null) {
            command.retries = newRetries;
        }
        store.put(command);
    }
}

// 在主应用中注册sync事件
// navigator.serviceWorker.ready.then(registration => {
//     registration.sync.register('sync-plc-commands');
// });

3. 幂等性与重试机制

幂等性：对于写入PLC的指令，设计后端API和PLC指令本身应具备幂等性。这意味着即使同一个指令被多次发送到PLC，其效果也应该与发送一次相同。例如，不是“增加数量”，而是“设置数量为X”。这能有效避免因网络重试而导致的数据重复或逻辑错误。
重试机制：在Service Worker中实现重试逻辑。每次发送失败时，更新IndexedDB中的retries字段。可以采用**指数退避（Exponential Backoff）**策略，即每次重试的间隔时间逐渐增加，以避免在网络持续不稳定时频繁重试造成资源浪费和服务器压力。同时，设置一个MAX_RETRIES上限，达到上限后，将指令标记为“永久失败”，并通知用户或管理员介入处理。
用户反馈：在Web应用前端，务必提供清晰的用户反馈。例如，通过一个小图标或文字提示用户当前有N条指令待同步，或同步成功/失败的状态，增强透明度和信任感。

部署与注意事项

HTTPS是强制的：Web NFC和Service Worker都要求在安全的上下文（HTTPS）中运行。
错误处理：细致的错误处理至关重要，包括网络错误、服务器响应错误、IndexedDB操作失败等。
数据清理：已成功同步的指令应及时从IndexedDB中清除，防止数据无限增长。
离线UI/UX：在离线状态下，前端界面应有所提示，并保持可用性。告知用户当前操作将在网络恢复后同步。
版本控制：Service Worker的更新机制需要注意，确保用户始终运行最新版本的Service Worker。
PLC指令的复杂性：PLC指令的写入通常非常具体且序列敏感。在设计commandData时，需要充分考虑PLC的实际通信协议和指令结构，确保后端能正确解析和执行。

通过以上前端离线数据同步与可靠性策略，即使工业现场的网络像个“筛子”，我们也能确保Web NFC采集到的PLC指令数据安然无恙地抵达目的地，为工业生产的稳定运行保驾护航。这不仅是技术的实践，更是对生产效率和安全的一种承诺。

希望这套方案能为你提供一些启发，让你的工业Web应用在严苛的环境中也能游刃有余！

码农老李 WebNFC 离线同步 ServiceWorker