Game web chạy trên máy tôi nhưng lỗi trên điện thoại người khác: cái bẫy khi deploy

Tôi đã đưa một game web lên mạng.

Trên máy của tôi, game chạy bình thường. GitHub đã có code sau khi sửa. Deploy cũng báo thành công.

Thế nhưng trên một số điện thoại, game vẫn lỗi.

Trong Analytics, tôi thấy lỗi:

SyntaxError: Unexpected token '<'

Tôi đang làm JavaScript. Tại sao bỗng nhiên dấu “<” lại trở thành vấn đề?

Chuyện này xảy ra khi tôi phát triển ORA Quest. Điều đáng giá nhất không phải một dòng code thần kỳ, mà là hiểu lỗi này thường đang cố nói với mình điều gì.

Có thể dấu “<” không phải thủ phạm

Ban đầu tôi nghĩ mình viết sai cú pháp JavaScript. Có ký tự lạ? JSON bị hỏng? Thiếu dấu phẩy?

Nhưng với Unexpected token '<', một trong những việc đáng kiểm tra đầu tiên là: trình duyệt yêu cầu JavaScript hoặc JSON nhưng server lại trả HTML hay không.

Ví dụ trình duyệt tải game.js. Nó mong đợi JavaScript. Nhưng server thực tế trả về một trang lỗi bắt đầu bằng <!DOCTYPE html>.

Trình duyệt cố đọc nó như JavaScript, gặp ký tự < đầu tiên và dừng lại.

Vậy nên dấu đó chưa chắc là vấn đề. Có thể trình duyệt đơn giản là nhận sai loại nội dung.

Bug khó chịu nhất là bug không xảy ra với tất cả mọi người

Đây là phần khiến tôi mất thời gian nhất.

PC chạy được. Một số điện thoại chạy được. Nhưng điện thoại khác hoặc trình duyệt bên trong ứng dụng mạng xã hội lại lỗi.

Rất dễ rơi vào vòng lặp:

sửa code → deploy → mở trên PC của mình → chạy được → nghĩ rằng đã xong.

Tôi từng kiểm tra như vậy.

Nhưng nếu nguyên nhân liên quan đến cache, trình duyệt, file cũ hoặc một đường dẫn request cụ thể, máy của chính người phát triển có thể tạo cảm giác an toàn giả.

5 thứ tôi sẽ kiểm tra đầu tiên nếu gặp lại

1. Mở trực tiếp URL của file JS hoặc JSON đang lỗi.
2. Kiểm tra xem response có thật sự là JavaScript hoặc JSON không.
3. Xem có phải server đang trả trang 404, trang đăng nhập, trang WordPress hoặc HTML khác không.
4. Xác nhận file trên server production đúng với file mình mong đợi từ GitHub.
5. Thử trên thiết bị hoặc trình duyệt khác, tránh phụ thuộc vào cùng một cache.

Bước đầu tiên đặc biệt hữu ích.

Thay vì thấy “lỗi JavaScript” rồi sửa code liên tục, hãy hỏi trước:

URL này thực sự trả về cái gì?

Một câu hỏi đơn giản có thể giúp tránh rất nhiều lần sửa nhầm chỗ.

GitHub đúng không có nghĩa production cũng đúng

Đây cũng là một bài học đau nhưng đáng giá.

Code trên GitHub có thể đúng, nhưng thứ đến tay người dùng vẫn có thể khác.

Ở giữa có thể là hệ thống deploy, hosting, WordPress, cache server/CDN, cache trình duyệt và trình duyệt nằm trong ứng dụng.

Chỉ cần một lớp trả file cũ hoặc response bất ngờ là bạn sẽ rơi vào tình huống: “Nhưng mình sửa rồi mà?”

Vì vậy, định nghĩa “đã sửa” của tôi đã thay đổi.

Fix chưa xong khi commit đúng. Nó chỉ xong khi URL production chạy được trong điều kiện gần với người dùng thật.

Đừng chỉ xóa lỗi — hãy làm cho lần lỗi tiếp theo dễ hiểu hơn

Trước đây tôi chỉ muốn lỗi biến mất càng nhanh càng tốt.

Bây giờ tôi còn cố để lại đủ thông tin để hiểu nó nếu nó quay lại.

File nào lỗi? URL nào được gọi? Môi trường nào? Build nào đang chạy?

Khi có các dữ liệu đó, lần sau câu hỏi sẽ không còn là “lại cái bug bí ẩn này”, mà là “có phải cùng nguyên nhân với lần trước không?”.

Đó không phải phần hào nhoáng của phát triển sản phẩm, nhưng với một người tự vận hành dịch vụ, nó có thể đáng giá hơn việc thêm một tính năng mới.

Làm sản phẩm một mình đôi khi là hiểu thực tế nhiều hơn là viết code

Trước khi làm game web, tôi nghĩ phát triển game chủ yếu là tạo nhân vật, viết câu chuyện và lập trình.

Thực tế, rất nhiều thời gian dành cho những câu hỏi như: tại sao chỉ thiết bị này lỗi? Tại sao JavaScript của hôm qua vẫn xuất hiện? Tại sao URL JSON lại trả HTML?

Mỗi lần hiểu được một lỗi, phạm vi thứ tôi có thể làm tiếp lại rộng hơn một chút.

Bài học lớn nhất từ Unexpected token '<' là:

code bạn viết và file người dùng thật sự nhận được không phải lúc nào cũng giống nhau.

Nếu bạn đang gặp lỗi này, trước khi viết lại JavaScript, hãy mở trực tiếp URL JS hoặc JSON bị lỗi. Nếu thấy HTML, bạn đã có một manh mối rất lớn.

Tôi đang học những bài học này trong lúc làm ORA Quest. Nếu tò mò tất cả những lần debug đó cuối cùng tạo ra thứ gì, bạn có thể chơi thử miễn phí bản demo ORA Quest.