### **Vite 任意文件读取漏洞（CVE-2025-31486）分析与修复方案**

#### **漏洞概述**
- **漏洞名称**：Vite 任意文件读取漏洞（CVE-2025-31486）
- **影响范围**：Vite 6.2.4、6.1.3、6.0.13、5.4.16 及 4.5.11 之前的版本
- **漏洞类型**：高危（可导致服务器敏感文件泄露）
- **攻击方式**：攻击者可利用 `?inline&import` 或 `?raw?import` 绕过文件读取限制，读取服务器上的任意文件（如配置文件、环境变量等）。
- **受影响场景**：仅当 Vite 开发服务器被**显式暴露在公网**（使用 `--host` 或 `server.host` 配置）时才会受此漏洞影响。



---

### **漏洞验证**
如果你的项目使用了 Vite，可以通过以下方式检查是否受影响：
1. **检查 Vite 版本**：
   ```bash
   npm list vite
   ```
   或查看 `package.json` 中的 `vite` 版本。

2. **检查是否暴露公网**：
   - 检查 `vite.config.js` 是否包含：
     ```js
     server: {
       host: true, // 或指定 0.0.0.0
     }
     ```
   - 检查启动命令是否包含 `--host`：
     ```bash
     vite --host
     ```

---

### **修复方案**
#### **1. 升级至安全版本（推荐）**
官方已发布修复版本，请升级至以下或更高版本：
| 受影响版本 | 安全版本 |
|------------|----------|
| Vite 6.x   | ≥ 6.2.5  |
| Vite 5.x   | ≥ 5.4.17 |
| Vite 4.x   | ≥ 4.5.12 |

**升级命令**：
```bash
npm install vite@latest
# 或指定版本
npm install vite@6.2.5
```

#### **2. 临时缓解措施（若无法立即升级）**
- **禁用公网访问**：
  - 移除 `vite.config.js` 中的 `host: true` 或 `host: '0.0.0.0'` 配置。
  - 避免使用 `vite --host` 启动开发服务器。
  
- **限制访问 IP**：
  - 使用防火墙（如 `ufw`、`iptables`）或云安全组策略，仅允许可信 IP 访问开发服务器端口（默认 `5173`）。

- **使用反向代理**：
  - 通过 Nginx/Apache 代理 Vite 开发服务器，并配置访问控制。

#### **3. 检查依赖项**
某些框架（如 Vue/React）可能间接依赖旧版 Vite，需检查并更新：
```bash
npm update
```

---

### **漏洞影响验证**
升级后，尝试构造恶意请求测试是否修复：
```bash
curl "http://your-server:5173/path/to/sensitive/file?raw&import"
```
若返回 `403` 或文件内容未被泄露，则说明修复成功。

---

### **注意事项**
1. **备份数据**：升级前建议对项目进行快照或代码备份。
2. **生产环境**：Vite 开发服务器**不应长期暴露在公网**，生产环境应使用 `vite build` 构建静态文件并通过正式 Web 服务器（如 Nginx）部署。
3. **监控日志**：检查服务器日志是否有可疑文件读取请求。

---

### **参考链接**
- [Vite GitHub Releases](https://github.com/vitejs/vite/releases)
- [CVE-2025-31486 公告](https://github.com/advisories/GHSA-4r4m-qw57-chr8)

请尽快评估业务影响并采取修复措施，避免因敏感信息泄露导致安全事件。

漏洞修复1则

### **Debian 11 新建普通用户并允许远程登录（同时禁用 root 远程登录）**

#### **目标**
1. **禁止 root 远程 SSH 登录**（提升安全性）。
2. **新建普通用户**，并赋予 `sudo` 权限（以便需要时切换 root）。
3. **允许该用户远程 SSH 登录**。



---

### **步骤 1：禁止 root 远程登录**
修改 `/etc/ssh/sshd_config`：
```bash
sudo nano /etc/ssh/sshd_config
```
找到 `PermitRootLogin` 并修改为：
```
PermitRootLogin no
```
保存（`Ctrl+O`）并退出（`Ctrl+X`）。

**重启 SSH 服务**：
```bash
sudo systemctl restart sshd
```
验证 root 是否无法 SSH 登录：
```bash
ssh root@your_server_ip
```
（应该会提示 `Permission denied`）

---

### **步骤 2：新建普通用户**
#### **2.1 创建用户**
```bash
sudo adduser username
```
（替换 `username` 为你想要的用户名，如 `user1`）  
按提示设置密码和其他信息（可留空）。

#### **2.2 赋予 sudo 权限**
```bash
sudo usermod -aG sudo username
```
（`-aG` 表示追加到 `sudo` 组，不影响其他组）

#### **2.3 验证用户是否在 sudo 组**
```bash
groups username
```
应显示 `username : username sudo`。

---

### **步骤 3：允许新用户 SSH 登录**
#### **3.1 确保 SSH 允许密码登录（可选）**
如果使用密码登录（而非密钥），检查 `/etc/ssh/sshd_config`：
```bash
sudo nano /etc/ssh/sshd_config
```
确认以下配置：
```
PasswordAuthentication yes
```
（如果已改为 `no`，需改回 `yes` 或使用 SSH 密钥登录）

#### **3.2 重启 SSH 服务**
```bash
sudo systemctl restart sshd
```

---

### **步骤 4：测试远程登录**
#### **4.1 从本地机器测试登录**
```bash
ssh username@your_server_ip
```
输入密码后应成功登录。

#### **4.2 测试 sudo 权限**
```bash
sudo -l
```
或执行：
```bash
sudo whoami
```
应返回 `root`，并提示输入当前用户密码。

---

### **步骤 5（可选）：改用 SSH 密钥登录（更安全）**
#### **5.1 生成密钥对（本地机器）**
```bash
ssh-keygen -t ed25519
```
（默认保存在 `~/.ssh/id_ed25519` 和 `~/.ssh/id_ed25519.pub`）

#### **5.2 上传公钥到服务器**
```bash
ssh-copy-id username@your_server_ip
```
或手动复制：
```bash
cat ~/.ssh/id_ed25519.pub | ssh username@your_server_ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
```

#### **5.3 禁用密码登录（提升安全性）**
修改 `/etc/ssh/sshd_config`：
```
PasswordAuthentication no
```
重启 SSH：
```bash
sudo systemctl restart sshd
```

---

### **总结**
| 操作 | 命令 |
|------|------|
| 禁用 root 登录 | `PermitRootLogin no` + `sudo systemctl restart sshd` |
| 创建用户 | `sudo adduser username` |
| 赋予 sudo 权限 | `sudo usermod -aG sudo username` |
| 允许 SSH 登录 | 确保 `PasswordAuthentication yes` 或配置 SSH 密钥 |
| 测试登录 | `ssh username@server_ip` |

**安全建议：**
- 优先使用 **SSH 密钥登录**，禁用密码认证（`PasswordAuthentication no`）。
- 仅向必要用户授予 `sudo` 权限。
- 定期审查 `/etc/sudoers` 和 `/etc/ssh/sshd_config`。

这样既保证了安全性，又允许通过普通用户管理服务器。

如何禁用root登录

我的餐厅是一开单控餐吊灯开关，
客厅有一个主灯双控分别安装2个一开双控面板与客厅和过道
过道是4盏筒灯串联 然后使用两个一开双控面板控制 在过道进入地方 和过道结束地方

上面的线路都是单一控制的，我现在想在入户门加一个总的开关，
打开总开关就可以同时点亮上面提到的三个区域的这些灯。
且从下面的分路双联开关依然可以控制局部的房间是否亮灯
我不想使用智能开关方案  也不新增继电器 只是靠不同的开关面板，可以实现效果吗，也可以重新从0开始布线实现这个效果，只是使用不同类型的开关面板

应该怎样设计电路走线图。




不使用智能开关或继电器，仅通过传统开关面板组合实现您的需求是完全可行的，但需要重新设计布线方案。以下是纯物理开关的解决方案：

---

### **最终实现功能**
1. **入户总控**：三开单控开关（同时控制三个区域）
2. **分区独立控制**：
   - 餐厅：单控开关保留
   - 客厅：双控开关保留
   - 过道：双控开关保留
3. **互锁逻辑**：总关闭闭时强制全关，总控开启时各分区开关可独立控制

---

### **方案一：重新布线（最可靠方案）**
#### **所需开关面板**
| 位置         | 开关类型                | 数量 |
|--------------|-------------------------|------|
| 入户门       | **四开单控开关**        | 1    |
| 餐厅         | 一开单控开关（保留）    | 1    |
| 客厅         | 一开双控开关（保留）    | 2    |
| 过道两端     | 一开双控开关（保留）    | 2    |

#### **电路改造关键步骤**
1. **总火线分配**：
   - 从配电箱引出 **1条总火线** 接入入户门四开开关的公共端
   - 四开开关的4个输出端分别控制：
     - 通道1：餐厅灯
     - 通道2：客厅灯
     - 通道3：过道筒灯
     - 通道4：**预留备用**

2. **餐厅线路**：
   ``` 
   配电箱 → 总控开关第1路 → 餐厅单控开关 → 餐厅吊灯
   ```

3. **客厅双控系统**：
   ```
   配电箱 → 总控开关第2路 → 客厅第一个双控开关 → 第二个双控开关 → 客厅主灯
   （保持原有双控布线不变）
   ```

4. **过道双控系统**：
   ```
   配电箱 → 总控开关第3路 → 过道第一个双控开关 → 第二个双控开关 → 筒灯组
   （保持原有双控布线不变）
   ```

#### **操作逻辑**
- **总控开启**：打开入户门四开开关的1/2/3路，三个区域通电，各分区开关可独立控制
- **总控关闭**：关闭入户门开关，所有灯具强制断电（无视分区开关状态）

---

### **方案二：不重新布线（低成本改造）**
#### **所需开关面板**
| 位置         | 开关类型                | 数量 |
|--------------|-------------------------|------|
| 入户门       | **三开双控开关**        | 1    |
| 各分区       | 原有开关保持不变        | -    |

#### **接线原理**
1. **入户门三开双控开关**：
   - 每个子开关的**公共端**接火线输入
   - 每个子开关的**常开端**分别接三个区域的灯具火线

2. **分区开关改造**：
   - 将各分区原有开关的**火线输入端**改接到入户门开关对应的输出端

#### **布线示意图**
```
配电箱火线 → 入户门三开双控开关公共端
            ├→ 开关1常开 → 餐厅单控开关 → 餐厅灯
            ├→ 开关2常开 → 客厅双控系统 → 客厅灯
            └→ 开关3常开 → 过道双控系统 → 筒灯
```

#### **操作限制**
- 分区开关只有在总控对应通道开启时才有效
- 总控关闭时所有灯具强制断电

---

### **方案对比**
| 方案   | 优点                   | 缺点                   |
|--------|------------------------|------------------------|
| 方案一 | 控制逻辑清晰，可靠性高 | 需要重新布线           |
| 方案二 | 改动最小，成本最低     | 总控开关必须保持开启状态 |

---

### **最终建议**
推荐采用**方案一**（重新布线），虽然施工量较大，但能实现：
1. 真正的"一键全关"功能
2. 各分区开关可独立操作
3. 无逻辑冲突风险

如果需要具体接线图，我可提供手绘示意图说明关键连接点。施工时请注意：
- 所有改造需断电操作
- 建议使用电压笔验证线路
- 双控开关的"COM端"必须正确识别

总开关控制多区域照明的布线方案

在电气设计（尤其是天正电气等CAD软件）中，**开关的“位、联、控、极”** 是描述开关功能和结构的关键参数，具体定义如下：

---

### **1. 位（位数）**
- **定义**：指开关的 **独立操作单元数量**（即一个面板上有几个独立的开关按键）。  
- **示例**：  
  - **一位开关**：1个按键（如单独控制一盏灯）。  
  - **二位开关**：2个按键（如一个面板控制两盏灯）。  
- **图形表示**：  
  - 天正电气中，一位开关用单圆圈/方框，多位开关会并列多个符号（如 ○○ 表示两位）。



---

### **2. 联（联数）**
- **定义**：指开关的 **机械联动关系**，即多个开关按键是否通过机械结构同步操作。  
- **示例**：  
  - **单联开关**：按键独立操作（无联动）。  
  - **双联开关**：两个按键机械联动（如同时切断火线和零线）。  
- **注意**：  
  - “联”常用于描述 **多极开关的联动**（如双联双控开关），但日常设计中可能与“位”混用，需结合上下文区分。

---

### **3. 控（控制方式）**
- **定义**：指开关的 **电路控制路径数量**，即能接通或断开的电路点数。  
- **常见类型**：  
  - **单控（1K）**：1个控制点（如普通灯开关）。  
  - **双控（2K）**：2个控制点（如楼梯灯上下控制）。  
  - **多控（DK）**：3个及以上控制点（需配合中途开关实现）。  
- **图形区别**：  
  - 单控：单线；双控：双线；多控：十字/交叉线（见前文分析）。

---

### **4. 极（极数）**
- **定义**：指开关 **同时切断的导线数量**（通常针对火线、零线、地线）。  
- **常见类型**：  
  - **单极（1P）**：只切断火线（最常见家用开关）。  
  - **双极（2P）**：同时切断火线和零线（用于高安全需求场景）。  
  - **三极（3P）**：用于三相电路（工业用电）。  
- **天正表示**：  
  - 极数通常通过文字标注（如“1P”“2P”），图形符号本身可能无差异。

---

### **综合示例对比**
| 参数 | 定义                | 示例术语           | 应用场景          |
|------|---------------------|--------------------|-------------------|
| 位   | 独立按键数          | 一位、二位         | 面板开关布局设计  |
| 联   | 机械联动关系        | 单联、双联         | 多极同步切断      |
| 控   | 控制路径数          | 单控、双控、多控   | 多点控制电路      |
| 极   | 切断导线数（P）     | 单极（1P）、双极（2P） | 安全等级要求      |

---

### **天正电气中的操作提示**
1. **符号选择**：  
   - 通过命令 **“KG”（开关）** 插入时，需在属性框中设置 **位数、极数**，而“控”类型（单控/双控）直接选择对应图形块。  
2. **标注规范**：  
   - 极数通常标注为 **“1P”“2P”**，控数标注为 **“1K”“2K”**，位数可能省略或标为“1位”“2位”。  

---

### **常见混淆点**
- **“联” vs “极”**：  
  - “联”强调机械联动（如双联开关可同时操作两个电路）；  
  - “极”强调电气隔离（如双极开关同时切断火线和零线）。  
- **“位” vs “控”**：  
  - “位”是物理按键数量，“控”是逻辑控制路径（如二位双控开关：2个按键，每个按键控制2个路径）。

如果需要在天正电气9中绘制具体符号，可结合上述参数在属性栏中设置，或直接调用预设图块（如“双极双控开关”）。

---
---
一个家庭电路 一火一零一地进入用户家庭配电箱，首先是地线直接接到地线端子排；火线和零线则左零右火进入2p总空开 ，然后下面分两个回路，回路一是照明回路，采用一个2p的空开接了单控灯，双控灯，以及附加中途开关的三控灯；回路2为插座回路，火线零线加上地排的地线给多个插座供电。这是很单纯的一个电路环境。

现在情况有变，原本的二号回路为插座回路，我在卧室门口有一个一开双控的开关，用于控制卧式吸顶灯，接的是照明回路的火线入双控开关的L端子，然后L1/L2两个出线端子分别接一根线到床头开一开双控五孔开关的L1/L2，不过床头我的开关是一开五孔的集成开关，已经接入了插座回路的火线零线地线，这时候从床头插座的L端出线到灯的L端，然后从灯的N端直接接入漏保的N端。

这时候要求床头一开五孔双控插座要有六个接线柱才可以分别接插座回路和照明回路，互不干涉；、
下面有两个问题

问题一:      是不是所有一开双控五孔插座都有六个接线柱？如果没有，是不是可以用插座回路的火线/零线跳线到开关上使用照明，这样会不会不安全，没有完全隔离照明回路和插座回路。

而且如果有时候插座回路漏报跳闸了，维修时候如果不断开照明回路，那么此时这六个接线柱上其实照明回路的三根电线是带电状态的，维修风险变大了。  问题二: 所以是不是安装一个单独五孔插  和一个单独一开双控开关更合适？


针对您描述的电路改造需求和安全性问题，我将分点给出专业建议：

### 问题一分析：集成开关的接线安全性
1. **接线柱数量问题**：
   - 正规的「一开双控五孔插座」通常设计为6个接线柱（开关部分：L/L1/L2；插座部分：L/N/PE）。但部分廉价产品可能共用接线柱，需具体查看产品规格。
   - 若仅有5个接线柱（开关L与插座L共用），则会导致照明回路与插座回路直接并联，违反以下安全规范：
     * 违反分回路隔离原则（照明/插座应独立回路）
     * 导致插座漏保跳闸时照明回路反送电
     * 增加维修触电风险

2. **跳线使用的危险性**：
   - 绝对禁止用插座回路电源跳线给照明开关供电！这会导致：
     * 照明负载绕过照明回路保护（如过载不跳闸）
     * 插座漏保动作后开关仍带电（违反断电隔离原则）
     * 可能引发电击事故（维修时误判断电状态）

### 问题二解决方案：推荐安装方案
✅ **最优方案**：  
**分体安装「独立五孔插座」+「独立双控开关」**，优势包括：
1. 物理隔离照明/插座回路
2. 维修时可彻底断电
3. 符合《住宅电气设计规范》GB50096要求
4. 降低故障连锁风险

### 额外安全建议
1. **回路优化**：
   - 照明回路建议使用1P+N空开（非漏保）
   - 插座回路必须使用2P漏电保护器（30mA动作电流）

2. **接线规范**：
   ```mermaid
   graph TD
   照明回路火线-->双控开关1_L
   双控开关1_L1-->双控开关2_L1
   双控开关1_L2-->双控开关2_L2
   双控开关2_L-->吸顶灯_L
   吸顶灯_N-->照明回路零线
   插座回路-->五孔插座(L/N/PE独立接线)
   ```

3. **维修安全**：
   - 任何维修前必须同时断开两个回路电源
   - 用验电笔确认开关接线柱无电后再操作

### 典型违规接法的风险示例
若强行在5接线柱集成开关上混接：
- 当插座回路跳闸时，开关L端仍通过照明回路带电
- 维修人员断开插座空开后，测量开关L端会误判为断电（实际照明回路仍在供电）
- 可能引发严重电击事故

建议立即整改为分体安装方案，这是最符合电气安全规范的解决方案。

---
那我就采用分体安装2个面板的方式吧！  对于一开单控五孔插座，可以将插座回路零线和地线正常接入面板的零线和地线接线柱，插座回路的火线接入开关的L端，然后由L1跳线到插座部分的L孔，后期使用开关控制插座电器是否断电 这样的使用方式是否得体


### Answer

您描述的这种「一开单控五孔插座」接线方式（开关控制插座通断）是**合规且常见**的用法，但需要注意以下关键要点：

---

### ✅ **正确接线方案**
```mermaid
graph LR
插座回路火线-->开关_L
开关_L1-->插座_L
插座回路零线-->插座_N
插座回路地线-->插座_PE
```
*（开关仅控制火线通断，零/地线直连）*

---

### ⚠️ **必须遵守的安全规范**
1. **负载功率匹配**：
   - 开关额定电流必须≥插座回路空开电流（如16A插座需配16A开关）
   - 常见家用开关多为10A，若控制大功率电器（空调/电热水器等）可能引发开关触点熔焊

2. **用途限制**：
   - **推荐用于**：台灯、充电器、小家电等≤10A负载
   - **禁止用于**：冰箱/空调等需常通电设备（频繁开关损坏压缩机）

3. **接线验证**：
   - 必须用相位检测仪确认：
     * 开关**只切断火线**（零线始终直连）
     * 地线**永不经过开关**

---

### 📝 **对比分体安装的优劣**
| 方案 | 优点 | 缺点 |
|------|------|------|
| **一开单控五孔** | 节省墙面空间<br>统一美观 | 开关插座同回路<br>负载受限 |
| **分体安装** | 回路完全隔离<br>可独立控制大功率插座 | 占用更多墙面空间 |

---

### 🛠️ **实际应用建议**
1. **厨房/卫生间**：  
   建议分体安装（插座常通电，开关控制灯具）

2. **卧室床头**：  
   可采用您描述的接法控制小功率设备（如：开关L接插座回路火线，L1跳线到插座L，实现睡前一键断电台灯/手机充电器）

3. **特殊警告**：  
   若发现开关面板发热或出现电弧声，**必须立即停用**！这表示开关容量不足。

---

### 🧰 **维修安全提示**
即使开关关闭时：
- 插座N/PE端仍带电（零线直连）
- 检修时仍需断开回路空开

这种接线方式完全符合GB16915.1-2014《家用开关标准》，只要注意负载匹配即可安全使用。

电路开关的一些知识点

# Python logging log日志写入文件

[琅琊山二当家](https://blog.csdn.net/AlbertFly) 2018-07-05 18:58:32

分类专栏： [python](https://blog.csdn.net/albertfly/category_6802901.html)

转载: https://www.cnblogs.com/nancyzhu/p/8551506.html

 Python logging log日志写入文件_Flyer的后花园-CSDN博客  https://blog.csdn.net/albertfly/article/details/80931623

## 日志

日志是跟踪软件运行时所发生的事件的一种方法。软件开发者在代码中调用日志函数，表明发生了特定的事件。事件由描述性消息描述，该描述性消息可以可选地包含可变数据（即，对于事件的每次出现都潜在地不同的数据）。事件还具有开发者归因于事件的重要性；重要性也可以称为级别或严重性。



logging提供了一组便利的函数，用来做简单的日志。它们是 debug()、 info()、 warning()、 error() 和 critical()。

 

logging函数根据它们用来跟踪的事件的级别或严重程度来命名。标准级别及其适用性描述如下（以严重程度递增排序）：

| 级别       | 何时使用                                                     |
| :--------- | :----------------------------------------------------------- |
| `DEBUG`    | 详细信息，一般只在调试问题时使用。                           |
| `INFO`     | 证明事情按预期工作。                                         |
| `WARNING`  | 某些没有预料到的事件的提示，或者在将来可能会出现的问题提示。例如：磁盘空间不足。但是软件还是会照常运行。 |
| `ERROR`    | 由于更严重的问题，软件已不能执行一些功能了。                 |
| `CRITICAL` | 严重错误，表明软件已不能继续运行了。                         |

 

| 级别       | 数字值 |
| :--------- | :----- |
| `CRITICAL` | 50     |
| `ERROR`    | 40     |
| `WARNING`  | 30     |
| `INFO`     | 20     |
| `DEBUG`    | 10     |
| `NOTSET`   | 0      |

 

默认等级是`WARNING`，这意味着仅仅这个等级及以上的才会反馈信息，除非logging模块被用来做其它事情。

被跟踪的事件能以不同的方式被处理。最简单的处理方法就是把它们在控制台上打印出来。另一种常见的方法就是写入磁盘文件。

 

一、打印到控制台

```
import logging
logging.debug('debug 信息')
logging.warning('只有这个会输出。。。')
logging.info('info 信息')
```

由于默认设置的等级是warning，所有只有warning的信息会输出到控制台。

```
WARNING:root:只有这个会输出。。。
```

 

利用logging.basicConfig()打印信息到控制台

![复制代码](https://common.cnblogs.com/images/copycode.gif)

```
import logging
logging.basicConfig(format='%(asctime)s - %(pathname)s[line:%(lineno)d] - %(levelname)s: %(message)s',
                    level=logging.DEBUG)
logging.debug('debug 信息')
logging.info('info 信息')
logging.warning('warning 信息')
logging.error('error 信息')
logging.critical('critial 信息')
```

![复制代码](https://common.cnblogs.com/images/copycode.gif)

由于在logging.basicConfig()中的level 的值设置为logging.DEBUG, 所有debug, info, warning, error, critical 的log都会打印到控制台。

```
日志级别： debug < info < warning < error < critical
logging.debug('debug级别，最低级别，一般开发人员用来打印一些调试信息')
logging.info('info级别，正常输出信息，一般用来打印一些正常的操作')
logging.warning('waring级别，一般用来打印警信息')
logging.error('error级别，一般用来打印一些错误信息')
logging.critical('critical 级别，一般用来打印一些致命的错误信息,等级最高')
```

所以如果设置level = logging.info()的话，debug 的信息则不会输出到控制台。

 

二、利用logging.basicConfig()保存log到文件

![复制代码](https://common.cnblogs.com/images/copycode.gif)

```
logging.basicConfig(level=logging.DEBUG,#控制台打印的日志级别
                    filename='new.log',
                    filemode='a',##模式，有w和a，w就是写模式，每次都会重新写日志，覆盖之前的日志
                    #a是追加模式，默认如果不写的话，就是追加模式
                    format=
                    '%(asctime)s - %(pathname)s[line:%(lineno)d] - %(levelname)s: %(message)s'
                    #日志格式
                    )
```

![复制代码](https://common.cnblogs.com/images/copycode.gif)

如果在logging.basicConfig()设置filename 和filemode，则只会保存log到文件，不会输出到控制台。

 

三、既往屏幕输入，也往文件写入log

 

logging库采取了模块化的设计，提供了许多组件：记录器、处理器、过滤器和格式化器。

- Logger 暴露了应用程序代码能直接使用的接口。
- Handler将（记录器产生的）日志记录发送至合适的目的地。
- Filter提供了更好的粒度控制，它可以决定输出哪些日志记录。
- Formatter 指明了最终输出中日志记录的布局。

Loggers:

Logger 对象要做三件事情。首先，它们向应用代码暴露了许多方法，这样应用可以在运行时记录消息。其次，记录器对象通过严重程度（默认的过滤设施）或者过滤器对象来决定哪些日志消息需要记录下来。第三，记录器对象将相关的日志消息传递给所有感兴趣的日志处理器。

常用的记录器对象的方法分为两类：配置和发送消息。

这些是最常用的配置方法：

Logger.setLevel()指定logger将会处理的最低的安全等级日志信息, debug是最低的内置安全等级，critical是最高的内建安全等级。例如，如果严重程度为INFO，记录器将只处理INFO，WARNING，ERROR和CRITICAL消息，DEBUG消息被忽略。
Logger.addHandler()和Logger.removeHandler()从记录器对象中添加和删除处理程序对象。处理器详见Handlers。
Logger.addFilter()和Logger.removeFilter()从记录器对象添加和删除过滤器对象。

### Handlers

`处理程序`对象负责将适当的日志消息（基于日志消息的严重性）分派到处理程序的指定目标。`Logger` 对象可以通过`addHandler()`方法增加零个或多个handler对象。举个例子，一个应用可以将所有的日志消息发送至日志文件，所有的错误级别（error）及以上的日志消息发送至标准输出，所有的严重级别（critical）日志消息发送至某个电子邮箱。在这个例子中需要三个独立的处理器，每一个负责将特定级别的消息发送至特定的位置。

常用的有4种： 

1)   logging.StreamHandler -> 控制台输出 


使用这个Handler可以向类似与sys.stdout或者sys.stderr的任何文件对象(file object)输出信息。

它的构造函数是：
StreamHandler([strm])
其中strm参数是一个文件对象。默认是sys.stderr


2)  logging.FileHandler -> 文件输出


和StreamHandler类似，用于向一个文件输出日志信息。不过FileHandler会帮你打开这个文件。它的构造函数是：
FileHandler(filename[,mode])
filename是文件名，必须指定一个文件名。
mode是文件的打开方式。默认是’a'，即添加到文件末尾。


3)  logging.handlers.RotatingFileHandler -> 按照大小自动分割日志文件，一旦达到指定的大小重新生成文件 


这个Handler类似于上面的FileHandler，但是它可以管理文件大小。当文件达到一定大小之后，它会自动将当前日志文件改名，然后创建 一个新的同名日志文件继续输出。比如日志文件是chat.log。当chat.log达到指定的大小之后，RotatingFileHandler自动把 文件改名为chat.log.1。不过，如果chat.log.1已经存在，会先把chat.log.1重命名为chat.log.2。。。最后重新创建 chat.log，继续输出日志信息。它的构造函数是：
RotatingFileHandler( filename[, mode[, maxBytes[, backupCount]]])
其中filename和mode两个参数和FileHandler一样。
maxBytes用于指定日志文件的最大文件大小。如果maxBytes为0，意味着日志文件可以无限大，这时上面描述的重命名过程就不会发生。
backupCount用于指定保留的备份文件的个数。比如，如果指定为2，当上面描述的重命名过程发生时，原有的chat.log.2并不会被更名，而是被删除。


4)  logging.handlers.TimedRotatingFileHandler -> 按照时间自动分割日志文件 


这个Handler和RotatingFileHandler类似，不过，它没有通过判断文件大小来决定何时重新创建日志文件，而是间隔一定时间就 自动创建新的日志文件。重命名的过程与RotatingFileHandler类似，不过新的文件不是附加数字，而是当前时间。它的构造函数是：
TimedRotatingFileHandler( filename [,when [,interval [,backupCount]]])
其中filename参数和backupCount参数和RotatingFileHandler具有相同的意义。
interval是时间间隔。
when参数是一个字符串。表示时间间隔的单位，不区分大小写。它有以下取值：
S 秒
M 分
H 小时
D 天
W 每星期（interval==0时代表星期一）
midnight 每天凌晨



配置方法：

- `setLevel()`方法和日志对象的一样，指明了将会分发日志的最低级别。为什么会有两个`setLevel()`方法？记录器的级别决定了消息是否要传递给处理器。每个处理器的级别决定了消息是否要分发。
- `setFormatter()`为该处理器选择一个格式化器。
- `addFilter()`和`removeFilter()`分别配置和取消配置处理程序上的过滤器对象。

Formatters

Formatter对象设置日志信息最后的规则、结构和内容，默认的时间格式为%Y-%m-%d %H:%M:%S，下面是Formatter常用的一些信息

| %(name)s            | Logger的名字                                                 |
| ------------------- | ------------------------------------------------------------ |
| %(levelno)s         | 数字形式的日志级别                                           |
| %(levelname)s       | 文本形式的日志级别                                           |
| %(pathname)s        | 调用日志输出函数的模块的完整路径名，可能没有                 |
| %(filename)s        | 调用日志输出函数的模块的文件名                               |
| %(module)s          | 调用日志输出函数的模块名                                     |
| %(funcName)s        | 调用日志输出函数的函数名                                     |
| %(lineno)d          | 调用日志输出函数的语句所在的代码行                           |
| %(created)f         | 当前时间，用UNIX标准的表示时间的浮 点数表示                  |
| %(relativeCreated)d | 输出日志信息时的，自Logger创建以 来的毫秒数                  |
| %(asctime)s         | 字符串形式的当前时间。默认格式是 “2003-07-08 16:49:45,896”。逗号后面的是毫秒 |
| %(thread)d          | 线程ID。可能没有                                             |
| %(threadName)s      | 线程名。可能没有                                             |
| %(process)d         | 进程ID。可能没有                                             |
| %(message)s         | 用户输出的消息                                               |

 

需求：

输出log到控制台以及将日志写入log文件。
保存2种类型的log， all.log 保存debug, info, warning, critical 信息， error.log则只保存error信息，同时按照时间自动分割日志文件。

![复制代码](https://common.cnblogs.com/images/copycode.gif)

```
import logging
from logging import handlers

class Logger(object):
    level_relations = {
        'debug':logging.DEBUG,
        'info':logging.INFO,
        'warning':logging.WARNING,
        'error':logging.ERROR,
        'crit':logging.CRITICAL
    }#日志级别关系映射

    def __init__(self,filename,level='info',when='D',backCount=3,fmt='%(asctime)s - %(pathname)s[line:%(lineno)d] - %(levelname)s: %(message)s'):
        self.logger = logging.getLogger(filename)
        format_str = logging.Formatter(fmt)#设置日志格式
        self.logger.setLevel(self.level_relations.get(level))#设置日志级别
        sh = logging.StreamHandler()#往屏幕上输出
        sh.setFormatter(format_str) #设置屏幕上显示的格式
        th = handlers.TimedRotatingFileHandler(filename=filename,when=when,backupCount=backCount,encoding='utf-8')#往文件里写入#指定间隔时间自动生成文件的处理器
        #实例化TimedRotatingFileHandler
        #interval是时间间隔，backupCount是备份文件的个数，如果超过这个个数，就会自动删除，when是间隔的时间单位，单位有以下几种：
        # S 秒
        # M 分
        # H 小时、
        # D 天、
        # W 每星期（interval==0时代表星期一）
        # midnight 每天凌晨
        th.setFormatter(format_str)#设置文件里写入的格式
        self.logger.addHandler(sh) #把对象加到logger里
        self.logger.addHandler(th)
if __name__ == '__main__':
    log = Logger('all.log',level='debug')
    log.logger.debug('debug')
    log.logger.info('info')
    log.logger.warning('警告')
    log.logger.error('报错')
    log.logger.critical('严重')
    Logger('error.log', level='error').logger.error('error')
```

![复制代码](https://common.cnblogs.com/images/copycode.gif)

屏幕上的结果如下：

```
2018-03-13 21:06:46,092 - D:/write_to_log.py[line:25] - DEBUG: debug
2018-03-13 21:06:46,092 - D:/write_to_log.py[line:26] - INFO: info
2018-03-13 21:06:46,092 - D:/write_to_log.py[line:27] - WARNING: 警告
2018-03-13 21:06:46,099 - D:/write_to_log.py[line:28] - ERROR: 报错
2018-03-13 21:06:46,099 - D:/write_to_log.py[line:29] - CRITICAL: 严重
2018-03-13 21:06:46,100 - D:/write_to_log.py[line:30] - ERROR: error
```

由于when=D，新生成的文件名上会带上时间，如下所示。

![img](https://images2018.cnblogs.com/blog/412654/201803/412654-20180313210806712-650581417.png)