CSS Unminifier vs Prettier: Khi Nào Sử Dụng Mỗi Công Cụ

CSS Unminifier đọc CSS sản xuất đã minify và mở rộng lại - mỗi khai báo mỗi dòng - để bạn đọc hoặc debug CSS không có nguồn. Prettier định dạng CSS bạn đã viết, áp dụng quy tắc .prettierrc của nhóm. Dùng sai công cụ tạo ra kết quả không nhất quán.

Last reviewed: 2026-06-30

freetoolonline.com Editorial Team

Tiêu chí	CSS Unminifier	Prettier
Đầu vào	CSS sản xuất đã minify (1 dòng dài, ~5-200 KB)	Mã nguồn CSS bạn viết (có thể đọc, trong repository của bạn)
Mục tiêu	Đọc hoặc debug stylesheet mà bạn không sở hữu nguồn	Định dạng để commit; áp dụng phong cách .prettierrc của nhóm
Cấu hình	Không có - luôn 1 khai báo mỗi dòng, indent 4 khoảng trắng	Được điều khiển bởi .prettierrc (2 hoặc 4 khoảng, giới hạn 80 ký tự, dấu ngoặc kép)
CLI / hook	Không - chỉ là công cụ trình duyệt, không có quyền truy cập hệ thống tệp hoặc git	Có - npx prettier, lint-staged, Husky pre-commit hook

CSS Unminifier thực sự làm gì (và không thể làm gì)

CSS Unminifier thực sự làm gì (và không thể làm gì) là mở rộng CSS đã minify thành dòng để đọc trong trình duyệt - không khôi phục tên gốc mất vì tree-shaking.

CSS Unminifier trên trang web này đọc một chuỗi CSS được minify (loại được tạo bởi cssnano, csso, clean-css hoặc bất kỳ build sản xuất nào chạy CSS qua một trình minify) và phát ra cùng các quy tắc với indent đúng, ngắt dòng và một declaration trên một dòng. Công cụ chạy hoàn toàn trong trình duyệt của bạn - trang được xây dựng xung quanh phân tích trong trình duyệt của nội dung textarea, không tải lên, không tài khoản. Bản sao nguyên văn trên trang công cụ nói "stylesheet sản xuất được xây dựng và bạn cần đọc hoặc chỉnh sửa nó"; đó là trường hợp sử dụng canonical.

Những gì unminification khôi phục:

• Khoảng trắng giữa selector, declaration và khối quy tắc. Đầu ra có thể đọc từng dòng trở lại.
• Ngắt dòng sau mỗi declaration. Mỗi thuộc tính: giá trị; ngồi trên dòng riêng.
• Indent bên trong các khối quy tắc. Mỗi declaration được indent dưới selector của nó.

Những gì unminification KHÔNG và KHÔNG THỂ khôi phục:

• Comments. Hầu hết các trình minify sản xuất loại bỏ comments trước khi xuất (cssnano mặc định, csso mặc định). Một khi bị loại bỏ, các comments gốc đã biến mất - unminifier không có gì để đặt lại.
• Phong cách định dạng gốc. Unminifier tạo ra đầu ra canonical "một declaration trên một dòng". Nếu nguồn của bạn dùng một quy ước khác (danh sách selector đa dòng được indent, declaration nhóm theo danh mục trực quan, vendor prefix được canh chỉnh), quy ước đó không có trong tệp đã minify và không thể được tái xây dựng.
• Tên biến từ CSS-in-JS hoặc CSS Modules. Nếu pipeline build chạy CSS Modules hoặc một công cụ CSS-in-JS hash tên lớp (.SubmitButton_xY7g3, .modal-_2hqf), các tên lớp ngữ nghĩa gốc đã biến mất. Unminifier hiển thị các tên đã hash vì đó là những gì trong tệp.
• Source maps. Nếu build sản xuất không bảo tồn một mục sourceMap, unminifier không thể khôi phục các đường dẫn tệp gốc hoặc số dòng. Nó chỉ định dạng những gì có trong textarea.

Nếu mục tiêu của bạn là "đọc CSS đã minify này để tìm một quy tắc cụ thể", unminifier giao chính xác điều đó. Nếu mục tiêu của bạn là "khôi phục nguồn gốc", đó là một nhiệm vụ khác (và thường không thể).

Prettier (và IDE auto-format của bạn) làm một công việc khác - đây là đường

Prettier là một trình định dạng nguồn có quan điểm. Đầu vào của nó là mã nguồn CSS bạn viết (hoặc sắp viết), và đầu ra của nó là cùng CSS được viết lại theo một tệp cấu hình (thường là .prettierrc hoặc prettier.config.js trong gốc repo). Prettier được thiết kế để chạy trên mỗi lưu, trên mỗi commit, trong hook pre-merge trên CI - trình định dạng áp đặt một phong cách duy nhất trên toàn bộ nhóm. Hầu hết các tiện ích mở rộng trình chỉnh sửa (VS Code "Prettier - Code formatter", JetBrains "Prettier", Sublime "JsPrettier") kết nối nó vào hành động format-on-save.

Hai điều khiến Prettier khác với unminifier:

1. Prettier được điều khiển bởi cấu hình. Dấu chấm phẩy cuối, độ rộng indent (2 vs 4), xử lý khoảng trắng cuối, độ dài dòng, dấu ngoặc đơn vs dấu ngoặc kép bên trong url() - mỗi nhóm chọn một kết hợp khác nhau, mã hóa nó trong .prettierrc và Prettier áp đặt kết hợp đó trên mỗi tệp. Unminifier không có cấu hình; nó luôn tạo ra cùng đầu ra canonical "một quy tắc trên một dòng".
2. Prettier mong đợi đầu vào có thể đọc được. Prettier không được xây dựng để xử lý một stylesheet đã minify một dòng. Nó có thể chạy trên CSS đã minify và sẽ tạo ra một cái gì đó đã được định dạng, nhưng đầu ra sử dụng quy tắc độ dài dòng riêng của Prettier (mặc định 80 ký tự), quy ước nhóm riêng của Prettier và phong cách trích dẫn của Prettier - thường KHÔNG khớp với tệp mà unminifier sẽ tạo ra. Trường hợp xấu nhất (hiếm): Prettier có thể từ chối định dạng CSS mà nó coi là không đúng định dạng (một dấu ngoặc đóng thêm, một pseudo-class không hợp lệ) nơi unminifier chỉ phát ra bất kỳ byte nào nó nhận được.

Mô hình tinh thần đơn giản nhất: CSS Unminifier là một trình xem; Prettier là một trình viết. Trình xem là để nhìn vào một tệp bạn không sở hữu. Trình viết là để commit một tệp bạn sở hữu.

Đọc CSS đã triển khai nhanh chóng: khi nào CSS Unminifier là câu trả lời nhanh nhất

Ba quy trình làm việc là lãnh thổ canonical của CSS Unminifier. Trong cả ba, đầu vào là một stylesheet sản xuất đã minify và mục tiêu là đọc nó một lần, không commit gì:

• Gỡ lỗi một lỗi cụ thể trên sản xuất. Mở DevTools, nhìn vào quy tắc đã thắng, sao chép selector đầy đủ của nó, dán CSS đã minify vào unminifier, tìm selector. Đầu ra được unminify giúp dễ dàng scan lên thác và xem các quy tắc khác có thể đang chơi. Nhanh hơn cuộn qua một dòng 200 ký tự.
• Kiểm tra một stylesheet bên thứ ba. Nếu một thư viện vendor (Bootstrap, CSS biên dịch Tailwind, CSS của một widget nhúng) đang gây trở ngại với các kiểu của bạn và bạn không có nguồn, dán tệp đã minify vào unminifier và đọc các quy tắc trực tiếp. Thường bạn tìm thấy quy tắc vi phạm trong 30 giây.
• Bàn giao một bản sao sạch cho một đồng nghiệp. Một báo cáo lỗi từ QA đến với một tệp đính kèm CSS đã minify. Dán, unminify, chia sẻ đầu ra đã định dạng trong bình luận trình theo dõi lỗi để người đọc tiếp theo không phải cuộn ngang.

Trong cả ba, unminifier thắng vì nó ở trong trình duyệt, không yêu cầu cài đặt và tạo ra đầu ra mà bạn có thể tìm kiếm với Ctrl-F. Chạy Prettier trên cùng đầu vào yêu cầu hoặc một cài đặt cục bộ (npx prettier file.css ghi vào đĩa) hoặc dán vào một Prettier playground - cả hai chậm hơn một công cụ một-dán chạy trên phía khách hàng.

Viết mã nguồn CSS: khi nào Prettier là lựa chọn đúng

Ba quy trình làm việc thuộc về Prettier. Trong cả ba, đầu vào là mã nguồn CSS mà nhà phát triển viết và mục tiêu là định dạng nó để commit:

• Format-on-save trong trình chỉnh sửa. VS Code và JetBrains đều kết nối Prettier vào hành động định dạng khi một .prettierrc có mặt trong repo. Mỗi khi nhà phát triển lưu một tệp CSS, Prettier viết lại theo các quy tắc nhóm. Unminifier không thể được kết nối vào format-on-save (nó không có CLI; nó là một trang web) và sẽ bỏ qua các quy tắc .prettierrc dù sao.
• Hook pre-commit trên git. Các công cụ như lint-staged + husky chạy Prettier trên mỗi tệp CSS được stage trước khi commit đáp xuống. Diff luôn được định dạng Prettier. Người xem chỉ thấy các thay đổi logic, không phải drift khoảng trắng. Unminifier không có tích hợp hook.
• Kiểm tra định dạng CI. Một bước CI chạy prettier --check src/**/*.css. Nếu bất kỳ tệp nào không khớp với các quy tắc Prettier, build thất bại. Bước định dạng cục bộ của mỗi nhà phát triển khớp với các quy tắc nhóm. Unminifier không thể áp đặt một kiểm tra: đầu ra của nó là canonical-line-per-rule, khác với bất kỳ .prettierrc của nhóm.

Nếu bạn đang commit CSS, chạy Prettier (qua trình chỉnh sửa của bạn, hook pre-commit hoặc CLI). Nếu bạn đang đọc CSS bạn không sở hữu, dán nó vào CSS Unminifier. Làm điều ngược lại - chạy Prettier trên một stylesheet đã minify để "đọc nó" - tạo ra một đầu ra không khớp với quy ước nguồn của nhóm bạn VÀ không khớp với bất kỳ quy ước đọc CSS tiêu chuẩn nào. Đó là tệ nhất của cả hai thế giới.

Không công cụ nào có thể khôi phục sau khi build với tree-shaking

Không công cụ nào có thể khôi phục sau khi build với tree-shaking là selector chết và tên class gốc mà bundler đã bỏ khỏi CSS triển khai.

Các pipeline CSS sản xuất làm nhiều hơn minify. Hầu hết các chuỗi build hiện đại chạy một chuỗi các chuyển đổi loại bỏ thông tin, và một khi thông tin biến mất, không trình định dạng nào (unminifier hoặc Prettier) có thể đặt nó trở lại. Biết những gì đã bị loại bỏ giúp đặt kỳ vọng cho những gì đầu ra "được unminify" của bạn sẽ trông:

• Tree-shaking loại bỏ các quy tắc không sử dụng. Các công cụ như PurgeCSS, UnCSS và động cơ JIT của Tailwind biên dịch nguồn với HTML/JSX của ứng dụng và phát ra chỉ các quy tắc khớp với các tên lớp được sử dụng. Stylesheet đầu ra là một TẬP CON của nguồn, theo một thứ tự khác. Unminifier có thể định dạng tập con đó nhưng không thể nói cho bạn biết các quy tắc nào đã bị loại bỏ.
• Mangling tên biến trên CSS-in-JS hoặc CSS Modules. CSS Modules viết lại .button thành .Button_button_2hQF (hoặc ngắn hơn); các thư viện CSS-in-JS (styled-components, emotion) viết lại .MyButton thành .css-1n3v7p9. Các tên đã hash là xác định nhưng mờ. Unminifier hiển thị các tên đã hash vì đó là những gì trong tệp.
• Comments bị loại bỏ trước build. Hầu hết các trình minify loại bỏ comments /* ... */ theo mặc định. Một số bảo tồn các comments banner /*! preserve */ (tiêu đề giấy phép); phần còn lại biến mất trước khi tệp rời pipeline build. Không unminifier cũng không Prettier khôi phục chúng.
• Source maps tách rời. Nếu build phát ra một tệp style.css.map nhưng bạn chỉ có style.css, bạn không thể quay lại các số dòng gốc. Unminifier định dạng những gì bạn có; Prettier làm tương tự. Cả hai phụ thuộc vào việc bạn cùng lấy source map nếu bạn cần điều hướng nguồn gốc.
• Sụp đổ vendor prefix. Autoprefixer thường phát ra một quy tắc duy nhất với nhiều biến thể prefix (-webkit-, -moz-, -ms-, tiêu chuẩn). Sau khi minify, thứ tự prefix có thể được xáo trộn để cho đầu ra ngắn nhất. Unminifier hiển thị cho bạn thứ tự cuối cùng đó; đầu ra Autoprefixer gốc có thứ tự khác trong nguồn.

Nếu mục tiêu của bạn là "tái xây dựng hoàn toàn nguồn", câu trả lời là: mở kho git của build hoặc lấy source map khớp. Không CSS Unminifier cũng không Prettier có thể tái xây dựng những gì pipeline build đã loại bỏ.

Ghép unminifier với phần còn lại của bộ công cụ CSS

Nếu tệp bạn đang đọc đến từ build sản xuất của chính bạn và bạn sắp RE-minify nó sau khi đọc (con đường round-trip "xem, chỉnh sửa, gửi"), ghép unminifier với CSS Minifier trên trang web này cho chuyến quay về. Minifier đảo ngược bước định dạng (loại bỏ khoảng trắng và ngắt dòng trở lại) và tạo ra một tệp có thể triển khai một dòng. Hai công cụ cùng nhau bao gồm cả hai hướng của vòng lặp sản-xuất-tới-nguồn-tới-sản-xuất.

Nếu bạn không chắc chắn liếc tệp bạn có là một đầu ra "minifier" (khoảng trắng bị loại bỏ) hay một đầu ra "uglifier" / tree-shaker (các biến được đổi tên cùng), hướng dẫn CSS minifier vs uglifier vs tree-shaking giải thích cách phân biệt chúng trong một đoạn. Nếu bạn đang chọn một minifier vs một compressor (gzip/brotli), hướng dẫn minifier vs compressor bao gồm sự nhầm lẫn kế bên đó. Nếu bạn đang chạy một triển khai Cloud Run hoặc Lambda và lo lắng về các byte CSS cold-start, hướng dẫn cách minify CSS/JS cho cold start Cloud Run bao gồm trường hợp được điều khiển bởi ngân sách.

Các câu hỏi thường gặp

Đầu ra được unminify có giống nguồn CSS gốc không?

Gần như không bao giờ. Unminifier đảo ngược bước khoảng trắng nhưng không thể đảo ngược việc loại bỏ comments, mangling biến, tree-shaking hoặc sắp xếp lại vendor prefix. Xử lý đầu ra như "CSS sản xuất có thể đọc được", không phải "nguồn gốc". Nếu bạn cần nguồn gốc, lấy kho git của build hoặc source map.

Tại sao tên biến của tôi khác nhau sau khi tôi unminify?

Chúng không khác nhau - chúng là cùng các tên mà pipeline build đã viết vào tệp. Các chuỗi build hiện đại viết lại tên lớp thông qua CSS Modules hoặc hashing CSS-in-JS để cô lập phạm vi, nên stylesheet sản xuất chứa .Button_xY7g3 thay vì .Button. Unminifier hiển thị cho bạn những gì trong tệp; nó không thể un-hash các tên vì ánh xạ của build không có mặt.

Tôi có thể chạy Prettier trên đầu ra được unminify không?

Có, và kết quả sẽ được định dạng Prettier (khớp với bất kỳ bộ quy tắc .prettierrc nào mà bạn trỏ Prettier tới). Nhưng unminifier đã tạo ra một đầu ra canonical "một declaration trên một dòng" tốt cho việc đọc; chạy Prettier trên nó chỉ thay đổi phong cách định dạng để khớp với các quy tắc nhóm của bạn. Hầu hết người đọc không bận tâm. Nếu bạn sắp commit tệp như nguồn, thì có - chạy Prettier tiếp theo, vì Prettier khớp với định dạng commit của nhóm bạn.

CSS Unminifier có xử lý hashes lớp CSS Modules không?

Nó sẽ định dạng chúng tốt (các hashes là tên lớp CSS hợp lệ). Những gì nó không thể làm là ánh xạ chúng trở lại các tên đọc được người của nguồn bạn. Nếu bạn có source map của build, DevTools của bạn có thể hiển thị các tên người bằng cách ánh xạ ngược thông qua source map; chỉ unminifier không thể.

Có cách nào để khôi phục comments sau khi build không?

Chỉ nếu minifier của build được cấu hình để bảo tồn chúng (hầu hết không theo mặc định). Cấu hình build của bạn để giữ các comments banner /*! ... */ qua tùy chọn preserve hoặc comments: 'some' của minifier. Một khi bị loại bỏ, comments không thể khôi phục thông qua định dạng.

Liên quan

• CSS Unminifier - công cụ mà hướng dẫn này được viết để đi kèm. Dán CSS đã minify, trả về CSS được định dạng, chạy hoàn toàn trong trình duyệt của bạn.
• CSS Minifier - công cụ hướng ngược lại để re-minify sau khi đọc. Cùng thiết lập trong trình duyệt, không tài khoản.
• CSS minifier vs compressor - hướng dẫn đồng hành hướng tiến lên. Làm rõ thuật ngữ minifier-vs-gzip mà các nhà phát triển thường trộn.
• CSS minifier vs uglifier vs tree-shaking - hướng dẫn đồng hành về thứ tự pipeline build. Giải thích mỗi chuyển đổi thực sự làm gì và khi nào áp dụng mỗi cái.
• Cách minify CSS/JS cho cold-start Cloud Run - hướng dẫn triển khai cụ thể cho ngân sách cold-start.