Ứng dụng Replit chạy tốt ở bản xem trước nhưng lỗi sau khi xuất bản? Checklist cho nhà sáng lập

Bạn thử ứng dụng trong Replit, gửi link cho ai đó, và ngay lập tức nghe phản hồi rằng đăng nhập, lưu dữ liệu hoặc thanh toán không hoạt động. Trước khi nhờ Agent xây lại các tính năng đó, hãy dùng checklist triển khai production cho Replit này. Sự khác biệt giữa hai môi trường có thể giải thích lỗi mà không cần viết lại phần triển khai.

Vì sao ứng dụng chạy tốt ở bản xem trước Replit nhưng lỗi khi live?

Bản xem trước của Replit và ứng dụng đã xuất bản là hai môi trường riêng biệt. Ứng dụng live có thể có URL, cấu hình, dữ liệu và hành vi runtime khác với dự án bạn đang chỉnh sửa.

Hướng dẫn xuất bản của Replit giải thích rằng việc xuất bản tạo ra một bản triển khai production, và những chỉnh sửa sau đó sẽ không thay đổi bản này cho đến lần xuất bản tiếp theo. Trước tiên, hãy xác nhận bạn đang kiểm thử đúng bản phát hành dự định. Ghi lại URL công khai, thời điểm xuất bản gần nhất, thao tác bị lỗi và liệu lỗi có xảy ra trong một phiên trình duyệt mới hay không.

Đừng gom năm ảnh chụp màn hình không liên quan rồi nhờ Agent sửa toàn bộ ứng dụng. Hãy chọn một lỗi: ví dụ, một khách hàng mới nhận thông báo lỗi sau khi bấm Lưu. Ghi lại kết quả mong đợi, kết quả thực tế và thời điểm. Như vậy bạn có một điểm cụ thể để đối chiếu với log của ứng dụng đã xuất bản.

Ứng dụng có đang dùng đúng loại triển khai không?

Bản triển khai phải hỗ trợ đúng kiểu chương trình mà ứng dụng của bạn chạy. Một tập hợp tệp tĩnh và một ứng dụng full-stack có yêu cầu hosting khác nhau.

Tính đến tháng 10/2026, tài liệu về các loại triển khai của Replit phân biệt các loại Autoscale, Static, Reserved VM và Scheduled. Hãy kiểm tra loại triển khai trong phần cài đặt Publishing và so sánh với nhu cầu thực tế của ứng dụng.

Cùng tài liệu đó cho biết Static không tương thích với các ứng dụng được tạo bằng Replit Agent vì những ứng dụng này cần backend. Nếu ứng dụng đã được tùy chỉnh, hãy nhờ một lập trình viên xác nhận lệnh build và lệnh chạy. Mua máy cấu hình cao hơn sẽ không sửa được một route server bị thiếu hay một lệnh khởi động sai.

Các secret production cần thiết có thực sự sẵn sàng không?

Hãy kiểm tra thông tin xác thực và cấu hình mà ứng dụng đã xuất bản sử dụng, bao gồm tên và môi trường dự định của chúng. Một key dùng được trong lúc phát triển không chứng minh rằng tích hợp trên bản live đã được cấu hình đúng.

Hướng dẫn về Secrets của Replit chỉ bạn đến Publishing → Adjust settings → Production app secrets. Tài liệu cũng phân biệt secret nhạy cảm với các giá trị cấu hình không nhạy cảm. Hãy rà soát các mục bắt buộc tại đó, và không sao chép giá trị của chúng vào prompt khắc phục sự cố.

1. Yêu cầu danh sách tên các biến bắt buộc, nơi mỗi biến được đọc, và biến đó được dùng lúc build hay lúc runtime.
2. Kiểm tra rằng các mục production khớp chính xác với những tên đó và thuộc đúng tài khoản nhà cung cấp dự định.
3. Giữ thông tin xác thực của server ở phía server; biến frontend hay bundle trên trình duyệt không phải là nơi lưu secret.
4. Xuất bản lại khi nền tảng hoặc quy trình build yêu cầu, sau đó lặp lại thao tác ban đầu trên URL công khai.

Ứng dụng đã xuất bản có đang đọc đúng cơ sở dữ liệu không?

Hãy xác định cơ sở dữ liệu live trước khi coi việc thiếu bản ghi production là lỗi giao diện. Dữ liệu mẫu nhìn thấy khi phát triển có thể không phải là dữ liệu mà ứng dụng của khách hàng đang đọc.

Hướng dẫn về cơ sở dữ liệu development và production của Replit mô tả các môi trường riêng biệt và cách thiết lập khác nhau cho hạ tầng hiện tại và hạ tầng cũ. Hãy kiểm tra lựa chọn production trong công cụ Database và phần cài đặt Publishing áp dụng cho ứng dụng của bạn. Đừng mặc định rằng hướng dẫn dành cho một thế hệ dự án khác cũng khớp với dự án của bạn.

Hãy xét một ứng dụng danh bạ giả định. Bản xem trước liệt kê mười doanh nghiệp, nhưng trang live không có doanh nghiệp nào. Trước khi xây lại component danh sách, hãy kiểm tra xem production có bản ghi doanh nghiệp nào đã được duyệt hay không. Phần việc còn thiếu có thể là một bước nhập dữ liệu hoặc khởi tạo có chủ đích. Chỉ sao chép dữ liệu phù hợp để dùng thật, và bảo vệ các bản ghi khách hàng hiện có trước mọi thao tác nhập dữ liệu hay thay đổi schema.

Với một thao tác ghi bị lỗi, hãy thu thập thao tác đó và thông báo lỗi đã được ẩn thông tin nhạy cảm. Nhờ lập trình viên phân biệt lỗi kết nối với lỗi thiếu bảng, vi phạm ràng buộc hay lỗi phân quyền. Liên tục đổi chuỗi kết nối có thể che mất nguyên nhân ban đầu và vô tình khiến công việc phát triển trỏ vào sai dữ liệu.

Tệp và callback bên ngoài có hoạt động trên domain công khai không?

Hãy kiểm tra nơi lưu các tệp được tải lên và domain mà các dịch vụ bên ngoài gọi đến. Cả hai có thể trông đúng ở bản xem trước nhưng lại không phù hợp với ứng dụng đã xuất bản.

Với tệp tải lên, Replit App Storage cung cấp object storage lưu trữ lâu dài. Hãy kiểm tra cách triển khai hiện tại thay vì mặc định rằng các tệp ghi vào một thư mục runtime có được độ bền lưu trữ và kiểm soát truy cập mà sản phẩm của bạn cần. Sau một lần phát hành có kiểm soát, hãy thử tải lên, truy xuất và giới hạn quyền truy cập một tệp.

Với nhà cung cấp đăng nhập, webhook thanh toán và link trong email, hãy rà soát các origin được phép, endpoint đã đăng ký và URL quay lại với từng nhà cung cấp liên quan. Chúng phải trỏ đến đúng domain đã xuất bản ở những nơi cần thiết. Hãy kiểm thử trọn vòng: rời ứng dụng của bạn, hoàn tất thao tác ở phía nhà cung cấp, rồi quay lại một màn hình hữu ích.

Hãy duy trì một bảng kê tích hợp nhỏ: dịch vụ, môi trường, đường dẫn callback công khai, tên secret và người phụ trách. Bảng kê này chứa thông tin cấu hình, không chứa giá trị secret. Nó giúp việc rà soát khi đổi domain hoặc bàn giao về sau dễ dàng hơn nhiều.

Nên xác minh bản sửa trên môi trường live như thế nào?

Tái hiện thao tác ban đầu trên URL công khai, sau đó kiểm tra bằng chứng tương ứng trên production. Xuất bản thành công nghĩa là bản phát hành đã hoàn tất; nó không chứng minh mọi luồng sử dụng của khách hàng đều thành công.

Hướng dẫn Monitoring của Replit giải thích trạng thái request, thời gian phản hồi, mức sử dụng tài nguyên và log ứng dụng. Dùng thời điểm của thao tác bị lỗi để thu hẹp phạm vi điều tra. Mức dùng tài nguyên cao và lỗi ứng dụng là hai phát hiện khác nhau, vì vậy hãy chẩn đoán trước khi thay đổi cấu hình máy.

1. Dùng một tài khoản mới trên domain đã xuất bản và lặp lại chính xác luồng đang bị lỗi.
2. Xác nhận rằng bản ghi hoặc kết quả tích hợp mong đợi vẫn tồn tại sau khi tải lại trang.
3. Kiểm tra request hoặc log tương ứng trên server, sau đó thử một trường hợp lỗi lân cận một cách an toàn.
4. Lặp lại luồng chính trên điện thoại và xác minh rằng những hành vi vốn chạy tốt trước đó vẫn hoạt động.

Nếu bản triển khai vẫn cần thêm công việc phát triển thì sao?

Nếu các bước kiểm tra cấu hình không giải quyết được lỗi, hãy khoanh vùng công việc phát triển quanh đúng ranh giới đang hỏng. Chuẩn bị cách tái hiện lỗi, cài đặt triển khai, thông báo lỗi đã ẩn thông tin nhạy cảm và sơ đồ các dịch vụ liên quan.

Hãy dùng checklist production cho MVP xây bằng AI rộng hơn trước khi mở rộng lượng người dùng, hoặc hướng dẫn thoát vòng lặp sửa lỗi nếu các prompt lặp đi lặp lại đang gây ra lỗi hồi quy. Nếu cần hỗ trợ rà soát và phát hành phiên bản tiếp theo, hãy đặt lịch trao đổi về ứng dụng Replit của bạn. Chúng tôi có thể xác định bạn cần sửa cấu hình, một thay đổi code có trọng tâm hay một kế hoạch phát hành lớn hơn.