Reasonable structure of website design CSS_html/css_WEB-ITnose

Architecture CSS
Under the premise that current browsers generally support it, CSS has been given an unprecedented mission. However, the more you rely on CSS, the larger and more complex the style sheet file will become. Along with this comes the challenge of file maintenance and organization.
(Once upon a time) only one css file was enough? All the rules were gathered together, and it was very convenient to add, delete or modify them. But such days are long gone. When building a new website (now), you have to spend some time planning how to organize and structure the CSS.

Organization of files
The first step in building a css system is the formulation of an outline. (I think) the importance of CSS organization planning is comparable to the website directory structure. (Note: Use exaggerated words to help you remember better.) There is no one-size-fits-all solution, so we will discuss some basic organizational solutions and their respective pros and cons.

Main CSS file
You can usually use a main CSS file to place rules shared by all pages. This file will contain default fonts, links, headers, and other styles. With the main css file in place, we started exploring high-level organizational strategies.

Method 1: Based on prototype
The most basic strategy is to separate css files based on archetype page. If a website's homepage, subpages, and portfolio pages are designed differently, a prototype-based strategy can be used. (Under this strategy) Each page will have its own css file.
When the number of prototypes is not large, this method is simple, clear and effective. However, problems arise when page elements are not located in each prototype page step by step. If subpages and combination pages share certain elements, but the homepage does not, what should we do?
Put the shared elements into the main css file. This isn't the purest solution, but it works for some specific situations. But if the website is huge, the main css file will expand rapidly - which defeats the purpose of separating files: to avoid importing unnecessary large files.
Put a copy of the style code in the css files of the combination page and sub-page. (Doing this) means maintaining redundant code, and obviously we don't want that.
Create a new file shared by these two pages. This sounds great. But if there are only 10 lines of code, do we create this file just to share these 10 lines of code? (Note: Killing a chicken with a knife?) This method is very pure, but if the website is huge and there are many pairs of pages sharing a small number of elements (note: killing a chicken with a knife?) :For example, 30 pairs of pages each share 10 lines of code), which seems very cumbersome.
Create a separate css file containing styles for all shared elements. This method may be simpler, but it depends on the size of the site and the number of shared elements. There is a situation that will be very annoying: a large css file is imported, but only a small part of the style is used on the page?? Again, this violates the original intention of separating files.
This is what I call the overlap dilemma. There's a lot of overlap in fragmented CSS rules, and there's no completely clear-cut way to organize them.

Method 2: Based on page elements/blocks
If the website uses server-side include, this method will be very good. For example, if you use header include, it will have its own corresponding css file. The include in the footer or other parts can be done in the same way, just import your own css file. This method is simple and clean, but it may produce a lot of small css files.
For example, if the footer style only requires 20 lines of CSS code, it is not worthwhile to create a separate file. And this method will cause each page to contain a bunch of css files? Because there are as many css files as there are include.

Method 3: Based on tags
This solution is intuitive and practical, similar to the previous one. If the website has a total of 30 pages, 10 of which contain forms, then you can create a css file to specifically handle the style of the form, and import it only on these 10 pages. If the other 10 pages contain tables, create a file specifically to handle table styles...and so on.