Báo thức trên Mac có kêu khi đóng nắp máy không?
Có — trên macOS 13 Ventura trở lên, báo thức Clock đặt trước khi bạn đóng nắp máy vẫn sẽ kêu, vì nó lên lịch một sự kiện đánh thức hệ thống thay vì kiểm tra xem nắp máy có đang mở hay không. Điều thực sự ảnh hưởng đến kết quả là mức pin, chế độ Focus/Do Not Disturb, và — nếu bạn đã đang giữ cho Mac không ngủ khi đóng nắp vì lý do khác — cơ chế nào bạn dùng để làm việc đó.
Cách báo thức Clock trên macOS đánh thức Mac đang đóng nắp
Ứng dụng Clock, xuất hiện từ macOS 13 Ventura, cho phép bạn đặt báo thức đăng ký một sự kiện đánh thức hệ thống theo lịch với macOS. Khi đến giờ báo thức, hệ điều hành đánh thức Mac trong chốc lát để phát âm thanh — qua loa tích hợp, miễn là âm lượng không bị tắt tiếng và Focus hay Do Not Disturb không đang chặn nó — rồi có thể đưa Mac trở lại trạng thái ngủ. Đây cùng nhóm cơ chế mà hệ thống dùng cho khung giờ sao lưu Time Machine hay một sự kiện theo lịch của Energy Saver: một lần đánh thức được kích hoạt bởi đồng hồ, không phải bởi nắp máy.
Đó là lý do vì sao nắp máy không quan trọng với bản thân báo thức. Việc đánh thức diễn ra ở cấp hệ thống — không cần gắn màn hình ngoài, không cần bấm phím, cũng không cần mở nắp máy. Nó kích hoạt theo cùng một cách bất kể Mac đang đóng nắp trên bàn hay mở suốt từ đầu.
Có một sự nhầm lẫn khá phổ biến nên làm rõ ngay: chạy thứ gì đó như caffeinate, hay bất kỳ ứng dụng nào đang giữ một keep-awake assertion, không liên quan gì đến việc liệu lần đánh thức theo lịch này có kích hoạt được hay không. Đánh thức cho báo thức và ngăn ngủ do rảnh (idle-sleep) là hai hệ thống hoàn toàn tách biệt trong macOS. Bạn không cần chạy công cụ keep-awake nào để báo thức hoạt động, và việc có một công cụ như vậy đang chạy cũng không khiến báo thức dễ hay khó kêu đúng giờ hơn.
Nếu bạn đang dùng macOS 12 Monterey trở về trước, tất cả điều này không áp dụng — Clock lúc đó chưa có tính năng báo thức, nên cũng không có lần đánh thức theo lịch nào để dựa vào.
Khi độ tin cậy của báo thức thực sự giảm
Hai yếu tố thực sự ảnh hưởng là pin và Focus. Khi pin gần cạn, macOS có thể trì hoãn hoặc bỏ hẳn lần đánh thức theo lịch để bảo toàn lượng pin còn lại — đây là kiểu thận trọng vốn có, xuất hiện ở nhiều chỗ khác trong cách macOS quản lý năng lượng, chứ không phải riêng cho báo thức. Cắm sạc cho Mac với bất cứ việc gì bạn đang trông cậy vào sẽ loại bỏ luôn biến số này.
Chế độ Focus và Do Not Disturb có thể chặn âm thanh báo thức ngay cả khi lần đánh thức diễn ra đúng lịch — Mac vẫn thức dậy, báo thức vẫn 'kích hoạt' ở bên trong, nhưng bạn không nghe thấy gì. Nếu bạn đang dựa vào báo thức Clock cho việc gì đó quan trọng, hãy kiểm tra xem Clock có được phép phá vỡ Focus đang bật hay không.
Nếu bạn muốn kiểm tra xem lần đánh thức theo lịch có thực sự được đăng ký trên Mac hay không — hữu ích khi debug bất kỳ trường hợp nào không thức dậy đúng giờ, không chỉ riêng báo thức — hãy chạy pmset -g sched trong Terminal. Lệnh này liệt kê các sự kiện đánh thức và ngủ đang xếp hàng trên Mac, mỗi cái được gắn nhãn theo tiến trình đã lên lịch cho nó; một báo thức đang hoạt động thường xuất hiện trong danh sách đó cùng với những thứ như Time Machine. Đây là một bước debug thật sự, không phải một sự đảm bảo — việc không bị Focus can thiệp hay pin không cạn vẫn quan trọng hơn những gì danh sách này cho thấy.
Cách miễn phí, có sẵn để Mac không bao giờ ngủ khi đóng nắp
Nếu bạn không muốn phụ thuộc vào cơ chế đánh thức theo lịch — bạn muốn Mac đơn giản là không bao giờ ngủ khi đóng nắp ngay từ đầu, để báo thức chỉ là âm thanh bình thường phát ra từ một máy đang chạy — macOS có một cách miễn phí, có sẵn, nhưng không phải cách mà mọi người thường nghĩ đến đầu tiên.
Đóng nắp máy kích hoạt một kiểu ngủ ở cấp thấp hơn (clamshell sleep) mà các công cụ chống ngủ do rảnh thông thường không đụng tới được. caffeinate, và bất kỳ ứng dụng nào xây trên cùng API keep-awake IOPMAssertionCreateWithName, chỉ chặn được ngủ *do rảnh* (idle). Đóng nắp mà không gắn màn hình ngoài, Mac vẫn rơi vào clamshell sleep bất kể đang giữ assertion nào — đây là lý do vì sao tình huống 'tôi chạy caffeinate mà đóng nắp máy vẫn ngủ' là một kết quả thật, đúng như dự kiến, chứ không phải lỗi.
Có hai cách thực sự ngăn được việc đó. Cách đầu tiên là gắn màn hình ngoài: khi có màn hình kết nối, macOS chạy chế độ clamshell tiêu chuẩn và Mac vẫn hoàn toàn thức dù đóng nắp — lúc này câu hỏi về đánh thức theo lịch không còn đặt ra nữa, vì máy chưa từng ngủ. Cách thứ hai, dành cho trường hợp đóng nắp mà không có màn hình ngoài, là một lệnh Terminal duy nhất: sudo pmset -a disablesleep 1. Đó chính là thiết lập hệ thống ghi đè việc ngủ khi đóng nắp trên pin, và nó yêu cầu mật khẩu admin vì đây là một ghi đè toàn cục, không phải quyền riêng cho từng ứng dụng.
Cái bẫy khi tự tay bật công tắc đó
disablesleep không chỉ áp dụng cho một lần chợp mắt hay một phiên làm việc — đây là một thiết lập toàn cục, tồn tại lâu dài. Một khi bạn đặt nó thành 1, nó vẫn có hiệu lực cho đến khi bạn chủ động đặt lại (sudo pmset -a disablesleep 0) hoặc khởi động lại Mac.
Bật nó lên trước một lần chờ báo thức ngắn rồi quên mất, và Mac sẽ tiếp tục bỏ qua việc ngủ khi đóng nắp vô thời hạn — không chỉ trong một tiếng bạn cần, mà mỗi lần bạn đóng nắp sau đó, kể cả khi máy nằm lại trong túi xách. Bản thân công tắc thô này không hề theo dõi mức pin hay nhiệt độ giúp bạn; nó làm đúng những gì bạn ra lệnh, chừng nào bạn còn để nguyên như vậy.
Đó là một rủi ro thật, không phải giả định: máy tiếp tục tiêu thụ điện và sinh nhiệt mà không có phần mềm nào kiểm tra lại. Đây chính là sự đánh đổi mà chế độ Closed-Lid của LidRun được thiết kế để tránh — tự tay bật công tắc đó, an toàn chỉ thắng được sự tiện lợi nếu bạn nhớ tự tay tắt nó lại.
Cách an toàn hơn: chế độ Closed-Lid nhận biết khối lượng công việc
Chế độ Closed-Lid của LidRun dùng chính công tắc pmset -a disablesleep đó — thông qua một helper có quyền hạn riêng, nên bạn không phải tự gõ lệnh sudo — nhưng nó luôn đi kèm việc bật với việc tắt lại: khi phiên làm việc dừng, khi bạn thoát ứng dụng, và nó còn đối chiếu lại mỗi lần khởi động phòng trường hợp lần chạy trước không thoát sạch sẽ. Bạn không phải ôm một thiết lập toàn cục mà tự mình phải nhớ để hủy.
Nó cũng có giới hạn, không phải một khóa giữ máy thức mù quáng. Bất kỳ phiên keep-awake nào của LidRun — kể cả Closed-Lid — mặc định dừng lại khi pin xuống dưới 20% (có thể chỉnh trong Settings), và một ngưỡng cứng ở 4% buộc Mac phải ngủ bất kể bạn đã cấu hình gì, vì dưới mức đó có thể không còn đủ pin để hoàn tất công việc một cách an toàn — cùng kiểu thận trọng cơ bản khiến chính macOS trì hoãn lần đánh thức báo thức theo lịch khi pin gần cạn. Nếu áp lực nhiệt tăng lên mức nghiêm trọng (critical) của hệ thống, cơ chế an toàn sẽ giải phóng việc giữ máy thức để Mac có thể giảm hiệu năng và hạ nhiệt, và có thể tùy chọn đưa máy vào ngủ thật sự nếu tình trạng nghiêm trọng vẫn tiếp diễn — bao quát cả trường hợp máy nằm trong túi bị quá nhiệt mà công tắc pmset thô hoàn toàn không quan tâm tới.
Đây là chỗ nối lại với câu hỏi về báo thức: nếu một phiên Closed-Lid hay Keep Awake đã đang chạy vì một lý do thật sự — một agent Claude Code đang hoàn tất tác vụ, một bản build dài, một lượt tải model — thì câu hỏi về báo thức tự nhiên không còn quan trọng nữa, như một hệ quả phụ. Mac đã thức sẵn, nên báo thức phát qua đường âm thanh bình thường mà không cần bước đánh thức nào. Đó cũng chính là cam kết chung của LidRun — agent đang chạy thì giữ máy thức; agent xong việc hoặc không an toàn thì thả ra và để máy ngủ — chứ không phải thứ được bật lên chỉ để trông chừng một cái báo thức. Nếu mục tiêu duy nhất của bạn là một báo thức đáng tin cậy, cơ chế đánh thức theo lịch có sẵn ở phần đầu bài đã đủ dùng khi cắm sạc; giá trị của LidRun thể hiện rõ khi bạn đã có sẵn một khối lượng công việc khiến nắp máy phải đóng vì lý do khác.
Quy tắc đặt máy vẫn luôn áp dụng
Chạy MacBook khi đóng nắp sinh nhiệt nhiều hơn so với khi mở nắp — màn hình tích hợp và một phần đường thoát khí của thân máy đều bị che kín trong trường hợp này. Không phần mềm nào thay đổi được quy luật vật lý đó, kể cả LidRun.
Với một khoảng chờ ngắn — báo thức còn 30 phút nữa trong khi một tác vụ nhỏ đang hoàn tất — lượng nhiệt sinh thêm hiếm khi đáng kể. Với một phiên chạy qua đêm, những lưu ý thông thường vẫn đúng: luôn cắm sạc, đặt Mac trên bề mặt cứng, phẳng, thoáng khí, và tránh đồ nội thất mềm hay túi xách đóng kín — nơi nhiệt không có đường thoát. Đặt hẹn giờ cho phiên làm việc để máy không thức lâu hơn mức bạn thực sự cần.
Cơ chế giải phóng vì nhiệt của LidRun giúp giảm rủi ro nếu nhiệt độ tăng cao, nhưng nó không thay thế được việc đặt máy đúng chỗ — hãy dùng nó một cách thận trọng và xem việc đảm bảo luồng khí là trách nhiệm của bạn, không phải của ứng dụng.
LidRun giữ công việc của bạn chạy tiếp khi đóng nắp, với cơ chế bảo vệ pin và nhiệt tích hợp sẵn.
Đã có LidRun? Đọc hướng dẫn thiết lập →
Mới biết đến LidRun? Xem bảng giá →
Câu hỏi thường gặp
Có. Trên macOS 13 Ventura trở lên, báo thức Clock lên lịch một sự kiện đánh thức hệ thống, nên Mac vẫn thức dậy trong chốc lát để kêu báo thức ngay cả khi đóng nắp — không cần màn hình hay nắp máy phải mở. Độ tin cậy cao nhất khi máy đang cắm sạc; pin quá thấp có thể khiến macOS trì hoãn lần đánh thức đó.
Những lý do phổ biến nhất là chế độ Focus hoặc Do Not Disturb đang chặn âm thanh báo thức dù lần đánh thức đã diễn ra đúng lịch, pin gần cạn khiến macOS trì hoãn việc đánh thức, hoặc bạn đang dùng macOS 12 trở về trước — phiên bản chưa có tính năng báo thức trong Clock.
Không, và trong mọi trường hợp cũng không cần thiết. Caffeinate chỉ chặn ngủ do rảnh (idle sleep), một cơ chế khác hoàn toàn so với ngủ khi đóng nắp (clamshell) mà việc đóng nắp máy kích hoạt — chỉ dùng caffeinate thôi sẽ không ngăn được điều đó nếu không gắn màn hình ngoài. Báo thức Clock dùng một đường đánh thức theo lịch riêng, không phụ thuộc vào việc có công cụ keep-awake nào đang chạy hay không.
Có hai cách có sẵn: gắn màn hình ngoài, giúp Mac chạy chế độ clamshell tiêu chuẩn và giữ máy thức hoàn toàn dù đóng nắp, hoặc chạy sudo pmset -a disablesleep 1 trong Terminal khi không có màn hình ngoài. Cách thứ hai là một thiết lập toàn cục, tồn tại lâu dài — nó vẫn bật cho đến khi bạn chạy sudo pmset -a disablesleep 0 hoặc khởi động lại máy, nên rất dễ quên là mình đang bật nó.
Có, một cách gián tiếp. Nếu LidRun đã đang giữ Mac thức cho một khối lượng công việc thật sự, báo thức sẽ phát qua đường âm thanh bình thường mà không cần đến bước đánh thức theo lịch nào cả. Tuy nhiên, LidRun không tự khởi động một phiên chỉ để đảm bảo báo thức kêu — nó được kích hoạt bởi việc phát hiện khối lượng công việc hoặc do bạn bật Keep Awake thủ công, và trong mọi trường hợp đều dừng theo cùng các ngưỡng pin và nhiệt độ.
Các ngưỡng pin và nhiệt độ của LidRun — tự dừng ở 20%, ngưỡng cứng ở 4%, và giải phóng vì nhiệt khi đạt mức nghiêm trọng — giúp giảm rủi ro cho một phiên chạy khi đóng nắp, nhưng việc đặt máy đúng chỗ vẫn là trách nhiệm của bạn. Hãy dùng bề mặt cứng, thoáng khí, luôn cắm sạc cho bất kỳ việc gì chạy qua đêm, và tránh để máy trong túi kín.
Có. macOS sẽ đánh thức MacBook đang ngủ trong chốc lát để phát báo thức từ Clock hay Calendar, xong lại cho máy ngủ tiếp — đóng nắp không chặn được, tiếng vẫn phát qua loa dù màn hình tắt đen. Nó chỉ không kêu nếu Mac đã tắt hẳn, hết pin, hoặc bị tắt tiếng.
Có. Tiếng báo thức vẫn phát qua loa tích hợp dù đã đóng nắp, vì macOS chỉ đánh thức máy vừa đủ để phát tiếng rồi lại ngủ tiếp. Nếu bạn không nghe thấy gì, hãy kiểm tra âm lượng hệ thống, và chắc chắn là Mac đang ngủ (chứ không phải đã tắt hẳn) và còn pin.
Gần như luôn luôn có — một báo thức đã hẹn trong Clock sẽ đánh thức Mac từ chế độ ngủ và reo đúng giờ dù nắp đang đóng. Ngoại lệ là Mac đã tắt nguồn, hết pin, hoặc được đặt bỏ qua lịch đánh thức. Nếu bạn thật sự trông cậy vào nó, hãy để Mac cắm điện và chỉ gập nắp lại thay vì tắt máy.