I'm just using GitHub Copilot for some common code-review suggestions. If no changes are necessary, I'll do a code-review ASAP :)

I'm just using GitHub Copilot for some common code-review suggestions. If no changes are necessary, I'll do a code-review ASAP :)

Seems copilot only find out typo~

Unlike method overriding, the "field" that the subclass redefines is its own and has no direct connection to the parent class's "field". If you want the parent class's "field" to be ignored, simply add the @ExcelIgnore annotation to the parent class's "field".
和方法重写不同，我认为子类变量和父类变量相互独立。如果想忽略父类变量，可以在其上加@ExcelIgnore注解

Unlike method overriding, the "field" that the subclass redefines is its own and has no direct connection to the parent class's "field". If you want the parent class's "field" to be ignored, simply add the @ExcelIgnore annotation to the parent class's "field". 和方法重写不同，我认为子类变量和父类变量相互独立。如果想忽略父类变量，可以在其上加@ExcelIgnore注解

Do you mean to update parent annotation? Hmmm...

In my opinion , we should not modify the parent behavior for child requirement.
e.g.
A parent class with two child classes

    class Fruit {        
        @ExcelProperty("parent1Field")
        private String field;
    }

    class Apple extends Fruit {
       @ExcelIgnore
        private String field;
    }
    class Orange extends Fruit {
         private String field;
    }

If ignore Apple field, we should not impact Orange. So it's fine to just update the child but not the parent.

This PR conflicts due to some previous changes. Would you be willing to fix these conflicts and submit it again?

Unlike method overriding, the "field" that the subclass redefines is its own and has no direct connection to the parent class's "field". If you want the parent class's "field" to be ignored, simply add the @ExcelIgnore annotation to the parent class's "field". 和方法重写不同，我认为子类变量和父类变量相互独立。如果想忽略父类变量，可以在其上加@ExcelIgnore注解

Do you mean to update parent annotation? Hmmm...

In my opinion , we should not modify the parent behavior for child requirement. e.g. A parent class with two child classes

    class Fruit {        
        @ExcelProperty("parent1Field")
        private String field;
    }

    class Apple extends Fruit {
       @ExcelIgnore
        private String field;
    }
    class Orange extends Fruit {
         private String field;
    }

If ignore Apple field, we should not impact Orange. So it's fine to just update the child but not the parent.

class Fruit {        
    @ExcelProperty("parent1Field")
    private String field;
}

class Apple extends Fruit {
   @ExcelIgnore
    private Integer field;
}
class Orange extends Fruit {
     private Boolean field;
}

Since hidden fields are independent of each other, how should we handle scenarios where only the parent class field or the subclass field is retained after export, rather than ignoring both?

as the independence, so you could find out all my given cases in commit are verified that no impact while call parent and child class separately.
e.g. the case parent4&6 and child4&6. ignore parent won't impact child export.

Unlike method overriding, the "field" that the subclass redefines is its own and has no direct connection to the parent class's "field". If you want the parent class's "field" to be ignored, simply add the @ExcelIgnore annotation to the parent class's "field". 和方法重写不同，我认为子类变量和父类变量相互独立。如果想忽略父类变量，可以在其上加@ExcelIgnore注解

Do you mean to update parent annotation? Hmmm...
In my opinion , we should not modify the parent behavior for child requirement. e.g. A parent class with two child classes

    class Fruit {        
        @ExcelProperty("parent1Field")
        private String field;
    }

    class Apple extends Fruit {
       @ExcelIgnore
        private String field;
    }
    class Orange extends Fruit {
         private String field;
    }

If ignore Apple field, we should not impact Orange. So it's fine to just update the child but not the parent.

class Fruit {        
    @ExcelProperty("parent1Field")
    private String field;
}

class Apple extends Fruit {
   @ExcelIgnore
    private Integer field;
}
class Orange extends Fruit {
     private Boolean field;
}

Since hidden fields are independent of each other, how should we handle scenarios where only the parent class field or the subclass field is retained after export, rather than ignoring both?

Might be I missed your point?
As this PR is going to fix the behavior of @ExcelIgnore in Child class, you can check my test case in commit, then list your expected behavior~

To minimize the potential impact on users of older versions, would it be possible to consider introducing a new annotation or adding a parameter to control whether parent class fields should be overridden, instead of modifying the behavior of @ExcelIgnore directly? Since @ExcelIgnore does not raise any errors, there’s a chance that some existing users may already rely on its current behavior.

To minimize the potential impact on users of older versions, would it be possible to consider introducing a new annotation or adding a parameter to control whether parent class fields should be overridden, instead of modifying the behavior of @ExcelIgnore directly? Since @ExcelIgnore does not raise any errors, there’s a chance that some existing users may already rely on its current behavior.

it depends on this is a bug or enhancement. as I found, there are several issues related this in easyexcel, even some pr merged for this, not sure why still unexpected case now.
in my opinion, i prefer to fix this logic within existing annotation, one hand is it always treating as a bug in legacy issues,another hand is in current FastExcel/EasyExcel as case in my commit , the default logic is following what declare in final/calling class, which means annotate child> exends parent

Maybe the writing of variables with the same name in parent and child is not standardized, and it involves the concept of hidden fields, which is easy to confuse with overriding. Is it more reasonable to make it an enhancement?

Maybe the writing of variables with the same name in parent and child is not standardized, and it involves the concept of hidden fields, which is easy to confuse with overriding. Is it more reasonable to make it an enhancement?

this fix is only covering the field both define at parent and child, it won't correct what user defined, just make sure the logic/behavior same within FastExcel.
we can move to other issues for the right usage or practice～