这个问题在配置管理实践里真的挺头疼——当minion从开发角色切换到生产，或者环境配置大变时，旧状态留下的冗余文件、软件包这类“遗留资源”很容易成为隐患，尤其是软件包这种可能被多个状态交叉依赖的资源，手动清理既繁琐又容易出错。下面是几个我在实际项目里验证过的实用方案，按优先级和实用性排序：

1. 基于pillar/grain的白名单式清理（推荐） #

核心思路是只保留当前环境明确需要的资源，把不在白名单里的旧资源自动清理掉，不用给每个资源单独写清理状态。

示例：Web站点配置清理 #

# 从pillar中获取当前环境允许的站点配置列表
{% set allowed_sites = pillar.get('web_server', {}).get('active_sites', []) %}

# 清理不在允许列表中的旧站点文件
remove_stale_sites:
  file.absent:
    - names:
        {% for site_file in salt['file.find']('/etc/nginx/sites-enabled', type='f') %}
        {% set site_name = site_file.split('/')[-1] %}
        {% if site_name not in allowed_sites %}
        - {{ site_file }}
        {% endif %}
        {% endfor %}

软件包场景的变通处理 #

软件包不能直接粗暴清理（避免误删系统依赖），可以结合pillar维护当前环境的软件包白名单，再对比已安装包做过滤：

{% set required_pkgs = pillar.get('production_pkgs', ['nginx', 'php-fpm']) %}
{% set installed_pkgs = salt['pkg.list_pkgs']() %}

remove_unwanted_pkgs:
  pkg.absent:
    - names:
        {% for pkg in installed_pkgs %}
        {% if pkg not in required_pkgs and not salt['pkg.is_dependency'](pkg) %}
        - {{ pkg }}
        {% endif %}
        {% endfor %}
    - onlyif: echo "确认清理非依赖的冗余包"

这里用pkg.is_dependency排除了系统依赖包，大幅降低误删风险。

2. 利用grains角色标识做状态完全隔离 #

给minion的grains打上明确的角色标签（比如grains.setval role production），然后在状态文件里用grains.filter_by区分不同角色的资源集合，同时自动清理冗余项：

{% set role_config = grains.filter_by({
    'dev': {
        'sites': ['app.conf', 'debug-endpoint.conf'],
        'packages': ['nginx', 'debug-tools']
    },
    'production': {
        'sites': ['app.conf'],
        'packages': ['nginx']
    }
}, default='production') %}

# 部署当前角色需要的站点配置
deploy_valid_sites:
  file.managed:
    - names:
        {% for site in role_config.sites %}
        - /etc/nginx/sites-enabled/{{ site }}
        {% endfor %}
    - source: salt://web/sites/{{ site }}.conf

# 清理当前角色不需要的旧站点
clean_stale_sites:
  file.absent:
    - names:
        {% for site_file in salt['file.find']('/etc/nginx/sites-enabled', type='f') %}
        {% set site_name = site_file.split('/')[-1] %}
        {% if site_name not in role_config.sites %}
        - {{ site_file }}
        {% endif %}
        {% endfor %}

# 管理软件包：确保只保留当前角色需要的
manage_packages:
  pkg.managed:
    - names: {{ role_config.packages }}
    - purge: True
    - require_in:
        - service: nginx

注意pkg.managed的purge: True参数会移除不在列表中的包，务必先在测试环境验证后再用。

3. 目录级别的原子替换（适合配置结构清晰的场景） #

如果你的配置目录是完全由Salt管理、没有动态生成文件的，用file.recurse的clean: True参数可以直接替换整个目录，自动删除不在源目录里的旧文件：

nginx_sites_dir:
  file.recurse:
    - name: /etc/nginx/sites-enabled
    - source: salt://web/sites/{{ grains.get('role') }}
    - clean: True
    - exclude_pat: '.gitkeep'  # 保留必要的空目录占位文件

4. 预验证+手动清理（适合环境变更不频繁的场景） #

如果担心自动清理误删关键资源，可以先运行测试命令查看差异：

salt 'target-minion' state.apply web.server test=True

这个命令会输出当前状态和期望状态的所有差异，包括即将被删除的资源。然后你可以根据输出编写一次性清理状态，或者直接用Salt命令批量删除：

salt 'target-minion' file.absent /etc/nginx/sites-enabled/debug-endpoint.conf

总结下来，白名单式清理是最通用的方案，既自动化又能避免过度清理；软件包场景一定要结合依赖检查；角色隔离的方式适合频繁切换环境的minion集群。

内容的提问来源于stack exchange，提问作者muffel